Delete (or Recycle) dialog not modeless

[KyferEz]

So, now that file copies are finally handled by XYcopy and are modeless again in Vista 64, here's another related problem that needs fixing: When I do a LARGE delete, the "Recycling" and "Deleting" dialogs are not modeless and therefore I cannot use XY while deleting files!

So, how about making deletes be handled by XYcopy as well?

Thanks Don!

[zer0]

Do you have "Enable background processing" ticked? If so, the help file states of "File operation progress modeless":

Code: Select all

Note: This setting is ignored if Enable background processing is ON.

[KyferEz]

Yes, I have that option checked. However if what you are telling me is true, then what is the point of background processing?

As I understood it, background process option was the method Don used to finally make copies modeless for Vista (as well as enable the possibility of more features). As you may know, Vista refuses to allow modeless copy and move dialogs from XY. If I am correct, that is why the "modeless" option is ignored, because it doesn't apply.

In any event, the modeless option DOES NOT work for vista 64, not for copies, moves, deletes, or delete to recycler, which is why I was excited for the XYcopy background processing in the first place! No matter what the case, I still need this delete dialog isn't modeless thing fixed for deletes,

[zer0]

As I understood it, background process option was the method Don used to finally make copies modeless for Vista (as well as enable the possibility of more features). As you may know, Vista refuses to allow modeless copy and move dialogs from XY. If I am correct, that is why the "modeless" option is ignored, because it doesn't apply.

Let's recall the historical timeline first.

In Win XP, copying/moving/etc was never modeless [in Explorer and XYplorer]. Currently, it's still modal in Explorer, but thanks to Don, it is modeless in XYplorer. In Vista RTM, file operations were always modeless, both in Explorer and XYplorer. Then Vista SP1 came around and problems started. XYplorer didn't like something -- what exactly is still unknown -- in SP1 and file operations dialogues stopped being modeless in XYplorer, whereas they were in Explorer. Same behaviour in Vista SP2 and Win 7 RTM. Therefore, I believe the "modeless" option is there for the benefit of XP users rather than Vista/Win 7.

In any event, the modeless option DOES NOT work for vista 64, not for copies, moves, deletes, or delete to recycler, which is why I was excited for the XYcopy background processing in the first place! No matter what the case, I still need this delete dialog isn't modeless thing fixed for deletes,

Which SP version do you have? Perhaps modeless deletion is in the pipeline as XYcopy evolves...this is where Don will be better placed to provide advice...he should be back this weekend after his holiday

[KyferEz]

I have Vista 64 SP2.

[zer0]

I have Vista 64 SP2.

I thought so. Also, to avoid confusion, by "Delete" dialogue, do you mean a dialogue that includes the progress bar that fills up as files are transferred to RB? Technically, such a dialogue window should appear very briefly as deletions are normally sent to local Recyclers, which only involve changes in FAT/MFT. I'd say that it's either a bug or Delete/Recycle modeless dialogues haven't been brought under the hood of XYcopy yet.

[nas8e9]

I'd say that it's either a bug or Delete/Recycle modeless dialogues haven't been brought under the hood of XYcopy yet.

If my forum memory serves (and the current Help file backs this up), moves within volume boundaries as well as deletions (which is what this is about) are currently excluded from background processing. I believe Don did this so to avoid XYplorer twiddling its thumbs while a long-running queue is dealt with: one can still do (non-queued) stuff while the queue is running.

[KyferEz]

zer0, yes, that's the dialog I meant. It is slow on Vista to do deletions or move to recycle bin large quantities of small files (2 or 3gb worth of 1kb to 100kb files).

mas8e9, Ok, but I really don't like it. I want modeless deletions! It takes vista too long to perform file delete tasks, so I want it fully modeless.

Here's what I want to see:
Either fix the modeless problem for Vista SP1/2, or make it so XYcopy does deletes. If XYcopy handles the deletes, to prevent XY from "twiddling it's thumbs", XYcopy should makes all delete commands take 1st priority in the queue and execute them immediately.

[nas8e9]

Here's what I want to see:
Either fix the modeless problem for Vista SP1/2, or make it so XYcopy does deletes. If XYcopy handles the deletes, to prevent XY from "twiddling it's thumbs", XYcopy should makes all delete commands take 1st priority in the queue and execute them immediately.

If I understand you correctly, there are two issues:
- Zer0 already covered that non-queued file operations should, with proper settings, result in a modeless, non-blocking dialog box but don't on Vista SP1 and beyond. Don's solution to this intractable problem is XYcopy, so that's where the solution will have to lie.
- As both a workaround as well as a final fix for the first issue, you suggest including deletes in XYcopy 2.0 with them "bubbling up" to the top of the queue. To me, that makes sense; the one possible problem (shared with the current implementation) may be that of consistency: deleting something that a queued file operation would later act on. In terms of implementation, I suspect that XYcopy 1.0 (using the Windows Shell file functions) can't reorder the queue for the simple reason that it would have to cancel (if possible at all; MSDN is a mystery to me ) instead of pause the currently active file operation, leading to state issues. XYcopy 2.0 (I read somewhere that Don scheduled this for 9.10) will use hand-rolled functions allowing much greater control by XYplorer.

[KyferEz]

Yes, you got it.

[admin]

Here's what I want to see:
Either fix the modeless problem for Vista SP1/2, or make it so XYcopy does deletes. If XYcopy handles the deletes, to prevent XY from "twiddling it's thumbs", XYcopy should makes all delete commands take 1st priority in the queue and execute them immediately.

If I understand you correctly, there are two issues:
- Zer0 already covered that non-queued file operations should, with proper settings, result in a modeless, non-blocking dialog box but don't on Vista SP1 and beyond. Don's solution to this intractable problem is XYcopy, so that's where the solution will have to lie.
- As both a workaround as well as a final fix for the first issue, you suggest including deletes in XYcopy 2.0 with them "bubbling up" to the top of the queue. To me, that makes sense; the one possible problem (shared with the current implementation) may be that of consistency: deleting something that a queued file operation would later act on. In terms of implementation, I suspect that XYcopy 1.0 (using the Windows Shell file functions) can't reorder the queue for the simple reason that it would have to cancel (if possible at all; MSDN is a mystery to me ) instead of pause the currently active file operation, leading to state issues. XYcopy 2.0 (I read somewhere that Don scheduled this for 9.10) will use hand-rolled functions allowing much greater control by XYplorer.

I think the best solution would be to always spawn Delete to a new separate background thread (if background processing is ON) and not append it to the queue. Simply because Delete is usually fast and you rather expect immediate action when you delete something.

I currently cannot see any problems with this strategy so I will hard-code it that way.

[nas8e9]

I think the best solution would be to always spawn Delete to a new separate background thread (if background processing is ON) and not append it to the queue. Simply because Delete is usually fast and you rather expect immediate action when you delete something.

I currently cannot see any problems with this strategy so I will hard-code it that way.

For my own understanding: does this mean that if you have a long-running copy job running (spawning one XYcopy task bar icon), would a delete command spawn a second XYcopy instance (with associated task bar icon)? Also, if the former two jobs are busy (the OP has a huge delete task), would giving a second delete command spawn a third XYcopy instance?

[admin]

I think the best solution would be to always spawn Delete to a new separate background thread (if background processing is ON) and not append it to the queue. Simply because Delete is usually fast and you rather expect immediate action when you delete something.

I currently cannot see any problems with this strategy so I will hard-code it that way.

For my own understanding: does this mean that if you have a long-running copy job running (spawning one XYcopy task bar icon), would a delete command spawn a second XYcopy instance (with associated task bar icon)? Also, if the former two jobs are busy (the OP has a huge delete task), would giving a second delete command spawn a third XYcopy instance?

Yes. (No taskbar icon on XP though.)

[nas8e9]

I think the best solution would be to always spawn Delete to a new separate background thread (if background processing is ON) and not append it to the queue. Simply because Delete is usually fast and you rather expect immediate action when you delete something.

I currently cannot see any problems with this strategy so I will hard-code it that way.

For my own understanding: does this mean that if you have a long-running copy job running (spawning one XYcopy task bar icon), would a delete command spawn a second XYcopy instance (with associated task bar icon)? Also, if the former two jobs are busy (the OP has a huge delete task), would giving a second delete command spawn a third XYcopy instance?

Yes. (No taskbar icon on XP though.)

So basically:
- copy and move commands are queued and handled by one and the same queue and XYcopy instance;
- delete commands are not queued but are handled (in parallel when two or more delete commands are issued) by a separate background process for each delete command issued.

Got it.

[admin]

I think the best solution would be to always spawn Delete to a new separate background thread (if background processing is ON) and not append it to the queue. Simply because Delete is usually fast and you rather expect immediate action when you delete something.

I currently cannot see any problems with this strategy so I will hard-code it that way.

For my own understanding: does this mean that if you have a long-running copy job running (spawning one XYcopy task bar icon), would a delete command spawn a second XYcopy instance (with associated task bar icon)? Also, if the former two jobs are busy (the OP has a huge delete task), would giving a second delete command spawn a third XYcopy instance?

Yes. (No taskbar icon on XP though.)

So basically:
- copy and move commands are queued and handled by one and the same queue and XYcopy instance;
- delete commands are not queued but are handled (in parallel when two or more delete commands are issued) by a separate background process for each delete command issued.

Got it.

If background processing is enabled:
- Copy and move commands are queued IF queuing is enabled, else they are spawned to separate background processes.
- Delete operations are always spawned to separate background processes.