Freeze during copying on Vista 32-bit

[nas8e9]

How is the responsiveness of the Windows Shell UI (the standard Windows status window shown in response to XYcopy.exe's calling of the Shell API)?

Do you mean the transfer progress dialogue window that shows up when I transfer files? It's accessable, expandable/shrinkable, minimisable/maximisable -- in other words, it works fine.

That makes it an "interesting" (in the Chinese meaning of the word...) bug: as I understand it, XYplorer.exe hands off the copying to XYcopy.exe, which in turn calls the Shell API. Both XYcopy.exe as well as the Shell API seem to do what they're supposed to do, but the originating app (XYplorer.exe), which should have its hands free at this point, stalls while XYcopy.exe and the Shell API are doing their thing. Oh, and it's not a problem across the board (I can't reproduce it, but let's wait what reports tomorrow brings).

Do you happen to have previous betas (> 8.90.0002 < 8.90.0009) handy to see if you can pinpoint where things went wrong for you?

Edit: And at *serious* risk of trying to teach your grandmother to suck eggs or something... , but does a fresh install with a fresh profile make any difference?

[zer0]

Do you happen to have previous betas (> 8.90.0002 < 8.90.0009) handy to see if you can pinpoint where things went wrong for you?

I have 8.90.0003 and it worked fine as I've reported in this very thread

[nas8e9]

Do you happen to have previous betas (> 8.90.0002 < 8.90.0009) handy to see if you can pinpoint where things went wrong for you?

I have 8.90.0003 and it worked fine as I've reported in this very thread

I didn't read back far enough. You can't say whether the current problem was in 8.90.0004, .0005 or .0006?

Also, does it make a difference *how* you initiate a copy? You mentioned a standard left-button drag-and-drop operation; does Edit > Copy To give the same problem?

[zer0]

Do you happen to have previous betas (> 8.90.0002 < 8.90.0009) handy to see if you can pinpoint where things went wrong for you?

I have 8.90.0003 and it worked fine as I've reported in this very thread

I didn't read back far enough. You can't say whether the current problem was in 8.90.0004, .0005 or .0006?

Also, does it make a difference *how* you initiate a copy? You mentioned a standard left-button drag-and-drop operation; does Edit > Copy To give the same problem?

Tried 8.90.0004 and it works fine. I think I may have an approximate idea of why there may be a problem. With .0003 and 0004, kicking off copying spawned a new task in the taskbar, separate from XYplorer (it had a large icon of XYcopy.exe icon). However, with .0009, no such task is spawned and instead the process is kicked off as part of XYplorer's taskbar task, as its child I guess. This is very reminiscent of how problems were happening before [XYcopy.exe came about]. I will see if I have betas after .0004 and before .0009, but for now I hope the above provides some clarity.

[nas8e9]

Do you happen to have previous betas (> 8.90.0002 < 8.90.0009) handy to see if you can pinpoint where things went wrong for you?

I have 8.90.0003 and it worked fine as I've reported in this very thread

I didn't read back far enough. You can't say whether the current problem was in 8.90.0004, .0005 or .0006?

Also, does it make a difference *how* you initiate a copy? You mentioned a standard left-button drag-and-drop operation; does Edit > Copy To give the same problem?

Tried 8.90.0004 and it works fine. I think I may have an approximate idea of why there may be a problem. With .0003 and 0004, kicking off copying spawned a new task in the taskbar, separate from XYplorer (it had a large icon of XYcopy.exe icon). However, with .0009, no such task is spawned and instead the process is kicked off as part of XYplorer's taskbar task, as its child I guess. This is very reminiscent of how problems were happening before [XYcopy.exe came about]. I will see if I have betas after .0004 and before .0009, but for now I hope the above provides some clarity.

I continue to see a different icon from XYplorer's in the taskbar denoting the transfer dialogue window representing XYcopy.exe. In other words, you probably have different settings active.

For comparison, I have the following:
- Configuration > File Operations:
- Background processing: enabled
- Queue file operations: enabled.
I see in the screenshot you posted here that you have both settings disabled (at least in 8.90.0009). Surely it can't be as easy as this?

If your copy of 8.90.0009 uses different settings than 8.90.0003 and 8.90.0004 with the above settings enabled in 8.90.0003, getting disabled in 8.90.0009 and getting re-enabled when reverting to 8.90.0004, something screwy is happening with your configuration (or configurations)?

[zer0]

I continue to see a different icon from XYplorer's in the taskbar denoting the transfer dialogue window representing XYcopy.exe. In other words, you probably have different settings active.

For comparison, I have the following:
- Configuration > File Operations:
- Background processing: enabled
- Queue file operations: enabled.
I see in the screenshot you posted here that you have both settings disabled. Surely it can't be as easy as this?

Yes sir! Enabling both of those did the trick, so it is as easy at that. Though it does beg the question of why not having them enabled (they're options, so it should work either way) is causing lock-ups. A bit too tired at the moment, but later on I'll take a closer look at changelogs/forum threads to find out more about those settings that nearly gave me a free haircut

[nas8e9]

I continue to see a different icon from XYplorer's in the taskbar denoting the transfer dialogue window representing XYcopy.exe. In other words, you probably have different settings active.

For comparison, I have the following:
- Configuration > File Operations:
- Background processing: enabled
- Queue file operations: enabled.
I see in the screenshot you posted here that you have both settings disabled. Surely it can't be as easy as this?

Yes sir! Enabling both of those did the trick, so it is as easy at that. Though it does beg the question of why not having them enabled (they're options, so it should work either way) is causing lock-ups. A bit too tired at the moment, but later on I'll take a closer look at changelogs/forum threads to find out more about those settings that nearly gave me a free haircut

Well, as friday night "entertainment" goes, it's a corker. (Although I may be a bit hazy on the definition of a corker, admittedly. Or entertainment. Whatever. )

[admin]

I continue to see a different icon from XYplorer's in the taskbar denoting the transfer dialogue window representing XYcopy.exe. In other words, you probably have different settings active.

For comparison, I have the following:
- Configuration > File Operations:
- Background processing: enabled
- Queue file operations: enabled.
I see in the screenshot you posted here that you have both settings disabled. Surely it can't be as easy as this?

Yes sir! Enabling both of those did the trick, so it is as easy at that. Though it does beg the question of why not having them enabled (they're options, so it should work either way) is causing lock-ups. A bit too tired at the moment, but later on I'll take a closer look at changelogs/forum threads to find out more about those settings that nearly gave me a free haircut

Enabling Background processing should be enough.

So you hadn't enabled it?

[zer0]

Enabling Background processing should be enough.

So you hadn't enabled it?

I had not, just went with the default. So Background processing = using XYcopy.exe?

[admin]

Enabling Background processing should be enough.

So you hadn't enabled it?

I had not, just went with the default. So Background processing = using XYcopy.exe?

Yes. You have a better idea for the caption?

[zer0]

Yes. You have a better idea for the caption?

I do -- Use XYcopy handler. The caption needs to clearly distinguish that XY's own mechanism is being employed rather than what it used to be.

[PeterH]

Yes. You have a better idea for the caption?

I do -- Use XYcopy handler. The caption needs to clearly distinguish that XY's own mechanism is being employed rather than what it used to be.

Do you know someone who knows what "XYcopy handler" is?
I think background processing is more understandable...

[zer0]

Do you know someone who knows what "XYcopy handler" is?
I think background processing is more understandable...

I can't speak for the number of those who know what XYcopy handler is, but I'm pretty sure a lot of people know what XYcopy is/will be As for "background processing", I don't see how that term describes abstraction of file operations. If anything, it speaks for some kind of suppression of operations onto the background, which isn't really the case.

[PeterH]

Do you know someone who knows what "XYcopy handler" is?
I think background processing is more understandable...

I can't speak for the number of those who know what XYcopy handler is, but I'm pretty sure a lot of people know what XYcopy is/will be As for "background processing", I don't see how that term describes abstraction of file operations. If anything, it speaks for some kind of suppression of operations onto the background, which isn't really the case.

I hope I'm not wrong in assuming the functions switches between background processing, that is asynchronous, and not-background = synchronous. If not we should talk about that

But I don't want to know the name of the program Don gave this functionality - as I don't want to know the name of any (sub-)routine of XY. You understand what I want to say?

[Creat]

As for "background processing", I don't see how that term describes abstraction of file operations. If anything, it speaks for some kind of suppression of operations onto the background, which isn't really the case.

Actually it is (from XYplorers point of view). You can continue working normally while copying takes place in the background. It's pretty much the whole idea!