nas8e9 wrote:I'm not sure about XYcopy.exe encountering a problem and then retrying without popping up some UI. After all, it's just a helper program that calls the same shell file functions as Windows Explorer. Have you actually seen a case where XYcopy.exe specifically or shell file operations generally, get stuck without reporting back? Also, XYcopy.exe definitely shows the shell UI for the file operation on Windows 7 (not sure about XP), which includes a Cancel button. You mean hitting the Cancel button doesn't cause XYcopy.exe to terminate?
I have encountered numerous situations when XYcopy.exe gets stuck. They are difficult to reproduce as I don't notice that XYcopy.exe is still running until after XYplorer is closed. And, as the XYcopy log is not retained between sessions, it's impossible to determine which job caused the problem.
As for the shell UI, it never appears for those stuck jobs. This leads me to recall that they get stuck in a "Queued" state and never come out of it.
nas8e9 wrote:If the latter is true, could that be because you have several jobs still in the queue at the time of closing XYplorer? I'm not completely sure what XYcopy.exe is meant to do when XYplorer.exe quits: should it process the entire queue at the time of closing XYplorer.exe or should it just complete the current job? I suspect the latter. (I seem to remember Don posting about how the XYcopy.exe instance that processes the queue, only gets one job at the time from the parent process.)
Personally, I never intentionally close XYplorer while there are jobs in the queue. I assume that if there is no shell UI showing, no jobs are running. With the
Background Bar being a small button that is relegated way outside of the peripheral vision, it's difficult to notice which state it is in.
nas8e9 wrote:- Have a tweak (or a GUI drop-down list in Config, plenty of space in File Ops
) that sets out the desired action -- exit/keep running -- applied to XYcopy when XYplorer is exited.
I'm not sure that's a simple request in that cancelling a job has huge potential to leave your files and folders in an inconsistent state (some *were* copied/moved/deleted, some not). The native UI shows a cancel button so it's possible in principle; I'm not sure however whether operations can be cancelled by the application calling the shell file functions. Since the queue version of XYcopy.exe by definition (well, probably; see above) will only process the job it currently has (although if memory serves, you do have some very long running jobs), it should in most cases complete fairly quickly. Again, I'd personally be uncomfortable with cancelling a job midway: I'm not a huge fan of inconsistency in my file system...
In my experience, jobs only get stuck in a queued state. Therefore, perhaps, such an option should cancel queued jobs.
Alternatively, maybe a pop-up that alerts a user that jobs are queued/running when he/she tries to exit XYplorer? We already have a tweak for such a pop-up when closing XYplorer via X in top RHC. Having a version tailored to situations when jobs are running would be appreciated. Its caption could be "There are background jobs queued/running. Are you sure you want to exit XYplorer?"
XYplorer Beta Club
