Exit XYcopy upon close of XYplorer

[zer0]

If the last ran script is remembered between sessions -- a convenience that I think is small one -- is it really not possible to also keep contents of "Background Jobs" dialogue between sessions? With logging not meeting my needs 100%, I'd rather review the queue to find potential culprits.

[zer0]

Code: Select all

v9.70.0006 - 2010-11-10 12:27
    ...
    * Logging To File:
      - NOTE: From now on, the setting is NOT remembered across sessions
        anymore!

Does this apply to those updating to this beta or to fresh installations only? If it's the former, then those of us who do logging would need to modify shortcut(s) to reflect the new switch and its values.

[admin]

Code: Select all

v9.70.0006 - 2010-11-10 12:27
    ...
    * Logging To File:
      - NOTE: From now on, the setting is NOT remembered across sessions
        anymore!

Does this apply to those updating to this beta or to fresh installations only? If it's the former, then those of us who do logging would need to modify shortcut(s) to reflect the new switch and its values.

Thinking 2.0 made me change this. Next version it will be remembered again. Sorry for the confusion.

[zer0]

Don,

I am in a bad need of an improvement in this area. Just updated to the latest beta and, even though no file ops were going on at the time, XYcopy was still running. Logging that a job has been added and triggered is all well and good, but if XYcopy remains running despite the green tick then something is amiss. I suppose I can workaround the issue by creating a CTB that points to this VBScript to check if it is running prior to closing XYplorer:

Code: Select all

set service = GetObject ("winmgmts:")

for each Process in Service.InstancesOf ("Win32_Process")
	If Process.Name = "XYcopy.exe" then
		wscript.echo "XYplorer is running"
		wscript.quit
	End If
next
wscript.echo "XYcopy is not running"

Still, it's not an ideal scenario as I wouldn't expect XYcopy.exe to be running unless XYplorer.exe is running too.

[admin]

I am in a bad need of an improvement in this area. Just updated to the latest beta and, even though no file ops were going on at the time, XYcopy was still running. ...

As long as I cannot reproduce an orphaned XYcopy I cannot do much.

[PeterH]

Did we talk about this before?
For me it's a question whether it's neccessary that XYCopy appears as "external" to XYPlorer?
As I understand there are other multithreaded applications, nevertheless appearing as one program to the user. I think it's annoying to see XYCopy in the windows taskbar.
For me XYCopy is an integral part of XY. It doesn't have it's own user interface - XY *is* it's interface. So I want just to see XY, ('the' interface,) no XYCopy.

[nas8e9]

Did we talk about this before?
For me it's a question whether it's neccessary that XYCopy appears as "external" to XYPlorer?
As I understand there are other multithreaded applications, nevertheless appearing as one program to the user. I think it's annoying to see XYCopy in the windows taskbar.
For me XYCopy is an integral part of XY. It doesn't have it's own user interface - XY *is* it's interface. So I want just to see XY, ('the' interface,) no XYCopy.

AFAIK multi-threading isn't workable for the language XYplorer is written in. The only way to do things in parallel is to spawn additional processes.

As far as visible UI is concerned, on Vista and Windows 7 the Shell UI for file operations produces a separate taskbar button, while running this in an additional thread in XYplorer.exe would make this additional taskbar button appear grouped with XYplorer.exe's button with the same image for both.

This visual separation is not ideal but given the above limitations, there's probably not much that can be done at the moment. It may be possible with XYcopy 2.0 (which will no longer use the Windows Shell file functions, thus not display the Shell UI for file operations) to fix this, although the grunt work will still have to be farmed out to a separate process. If XYplorer.exe manages the UI portion of the operation, it would be possible to improve this.

[zer0]

I am in a bad need of an improvement in this area. Just updated to the latest beta and, even though no file ops were going on at the time, XYcopy was still running. ...

As long as I cannot reproduce an orphaned XYcopy I cannot do much.

Catch 22 though, innit? Current logging ability isn't enough for me to ascertain the cause, which makes it difficult to point you in the right direction. Overall, with XYplorer being the parent of XYcopy, I'm not even sure it's kosher to allow it (XYcopy) to run without its dad in attendance.

[admin]

I am in a bad need of an improvement in this area. Just updated to the latest beta and, even though no file ops were going on at the time, XYcopy was still running. ...

As long as I cannot reproduce an orphaned XYcopy I cannot do much.

Catch 22 though, innit? Current logging ability isn't enough for me to ascertain the cause, which makes it difficult to point you in the right direction. Overall, with XYplorer being the parent of XYcopy, I'm not even sure it's kosher to allow it (XYcopy) to run without its dad in attendance.

I allow to exit XY and keep XYcopy running because the ongoing job should be allowed to finish even when the mothership is gone. What other option do you see?
(When XYcopy finishes its job and XYplorer is gone the XYcopy terminates itself. I never found a way to break this behavior.)

[zer0]

I allow to exit XY and keep XYcopy running because the ongoing job should be allowed to finish even when the mothership is gone. What other option do you see?(When XYcopy finishes its job and XYplorer is gone the XYcopy terminates itself. I never found a way to break this behavior.)

I think about it from a different angle: the mothership shouldn't be allowed to leave unless its children have finished their business. From my experience on occasions, something causes XYcopy to think that a job is still running -- perhaps a notification of completion isn't sent/received properly -- so it continues churning in vain. The trick is to determine what causes such a hiccup and logging on its own isn't sufficient as this problem occurs while a job is running.

[admin]

I allow to exit XY and keep XYcopy running because the ongoing job should be allowed to finish even when the mothership is gone. What other option do you see?(When XYcopy finishes its job and XYplorer is gone the XYcopy terminates itself. I never found a way to break this behavior.)

I think about it from a different angle: the mothership shouldn't be allowed to leave unless its children have finished their business. From my experience on occasions, something causes XYcopy to think that a job is still running -- perhaps a notification of completion isn't sent/received properly -- so it continues churning in vain. The trick is to determine what causes such a hiccup and logging on its own isn't sufficient as this problem occurs while a job is running.

I'll do this in the moment I can reproduce it.

[zer0]

I'll do this in the moment I can reproduce it.

We're back to square one -- existing toolset doesn't allow me to reliably capture enough data to create steps to reproduce. You scratch my back, I'll scratch yours.

[admin]

I'll do this in the moment I can reproduce it.

We're back to square one -- existing toolset doesn't allow me to reliably capture enough data to create steps to reproduce. You scratch my back, I'll scratch yours.

Later...

[admin]

Next version might fix this. (Needs XYcopy 1.00.0028)

[zer0]

OK, so we the last couple of betas I started noticing that XYcopy.exe began being orphaned again. As seen in the screenshot below, XYcopy.exe is still running despite no active background processing.

xycopy_orphant.PNG

Copy handler in question is v1.00.0031