Freeze during copying on Vista 32-bit

[admin]

The plugin name "XYcopy" is mentioned in the line below the checkboxes. I think that's clear.

BTW, I just wrote plugin with a mental footnote "Think about this again". Is maybe "Addon" the better term, or yet something else?

[nas8e9]

The plugin name "XYcopy" is mentioned in the line below the checkboxes. I think that's clear.

BTW, I just wrote plugin with a mental footnote "Think about this again". Is maybe "Addon" the better term, or yet something else?

Helper program?

[soja]

I don't mind "background processing." I wouldn't know what "use xycopy" means. But here's another suggestion that might work: "Launch copy operations in a separate process." This kind of mirrors the WE option "Launch folder windows in a separate process," so many people might understand right away what it means. Also, the tooltip could say it another way as well.

[admin]

I don't mind "background processing." I wouldn't know what "use xycopy" means. But here's another suggestion that might work: "Launch copy operations in a separate process." This kind of mirrors the WE option "Launch folder windows in a separate process," so many people might understand right away what it means. Also, the tooltip could say it another way as well.

A bit too long for the caption but a good idea for the tooltip!

[PeterH]

The plugin name "XYcopy" is mentioned in the line below the checkboxes. I think that's clear.

BTW, I just wrote plugin with a mental footnote "Think about this again". Is maybe "Addon" the better term, or yet something else?

Sure it is - but what does it mean? And why should I know it's name to select it's function?

What's interesting is what happens: do I copy by shell, or by own program (like XYcopy)?
Do I copy synchronous or asynchronous (maybe by XYcopy)?

So what I wanted to say is: if I have to select XYcopy I have to know what it stands for, e.g. asynchronous. If I select something like "asynchronous" or "background" I can know it generally.

[admin]

The plugin name "XYcopy" is mentioned in the line below the checkboxes. I think that's clear.

BTW, I just wrote plugin with a mental footnote "Think about this again". Is maybe "Addon" the better term, or yet something else?

Helper program?

Hm, English is not my language, but "Helper program"? Sounds not familiar. I think most users will have a rough idea what a plugin is (cf http://en.wikipedia.org/wiki/Plug-in_%28computing%29), so I think it will work here. I'll change to "XYcopy.exe" so everybody will understand that this is an additional file.

[j_c_hallgren]

Is maybe "Addon" the better term, or yet something else?

Hm, English is not my language, but "Helper program"? Sounds not familiar. I think most users will have a rough idea what a plugin is (cf http://en.wikipedia.org/wiki/Plug-in_%28computing%29), so I think it will work here.

After reading that wiki article, I'm not sure what is best...but the risk of using "plug-in", as I see it, is that some users may perceive that XY is now able to support external plug-ins from other vendors as has been requested here before but given that "add-on" is also used by Firefox and others for vendor/user coded items, it's not much better...

The only thing I can come up with after all this might be "extension module" which may seem a bit redundant but hopefully implies that it's only something that original developer might code.

[admin]

Is maybe "Addon" the better term, or yet something else?

Hm, English is not my language, but "Helper program"? Sounds not familiar. I think most users will have a rough idea what a plugin is (cf http://en.wikipedia.org/wiki/Plug-in_%28computing%29), so I think it will work here.

After reading that wiki article, I'm not sure what is best...but the risk of using "plug-in", as I see it, is that some users may perceive that XY is now able to support external plug-ins from other vendors as has been requested here before but given that "add-on" is also used by Firefox and others for vendor/user coded items, it's not much better...

The only thing I can come up with after all this might be "extension module" which may seem a bit redundant but hopefully implies that it's only something that original developer might code.

Yeah, I see.

Thinking about it, it's just for the GUI (I can explain everything with more words in the help). I could also simply skip the term and say:
XYcopy.exe v1.00.0013
or
Using XYcopy.exe v1.00.0013
or maybe
Copy Handler: XYcopy.exe v1.00.0013

[PeterH]

The sense is just to verify the version of XYcopy.exe, isn't it? Then I'd prefer the last phrase you sad.
Copy Handler: XYcopy.exe v1.00.0013
It describes short what's meant, and shows the version.

By the way, it's correct: plugins often are meant to be made by other people.

[zer0]

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!

Yes, but that's how copying should be happening anyway. Using XYcopy shouldn't change that as whatever it is in XYplorer that isn't playing ball since Vista SP1 is still there.

[zer0]

Code: Select all

v8.90.0010 - 2010-03-22 14:59
    * Configuration | File Operations:
      - Renamed "Background processing" to "Enable background
        processing".

I don't like being a pain in the ass about this, but this still does not convey that XYcopy is handling things. A caption like "Use XYplorer's file engine" is much better as it makes a distinct statement as to what a user is actually enabling, absolutely no ambiguity. Of course, once a person is explained that "Enable background processing" = enable XYcopy, it's in their mind but for first-timers it's a hell of a mental jump -- even I fell into that trap...

[zer0]

What I noticed last night -- using v8.90.0016 on Win 7 -- is that the file transfer dialogue is freezing if it is minimised/maximised during the final stages of each file being copied [to an external HDD]. Now I'm not an expert on such matters, so I am not sure if to point the finger of blame at the shell (final stages of write and some quick verification perhaps?) or AV software (scanning a newly-created file?), but minimising the same dialogue when copy was initiated in Explorer doesn't cause the same freeze.

Further, the time period during which minimising/maximising causes a freeze varies and I am somewhat sure that it is almost proportional to the size of each file: bigger file -> longer time period. Once whatever is going on in those moments has finished its business, the dialogue window returns to being a good boy...

[admin]

What I noticed last night -- using v8.90.0016 on Win 7 -- is that the file transfer dialogue is freezing if it is minimised/maximised during the final stages of each file being copied [to an external HDD]. Now I'm not an expert on such matters, so I am not sure if to point the finger of blame at the shell (final stages of write and some quick verification perhaps?) or AV software (scanning a newly-created file?), but minimising the same dialogue when copy was initiated in Explorer doesn't cause the same freeze.

Further, the time period during which minimising/maximising causes a freeze varies and I am somewhat sure that it is almost proportional to the size of each file: bigger file -> longer time period. Once whatever is going on in those moments has finished its business, the dialogue window returns to being a good boy...

Who knows what's going on inside V/W7? And who cares? We will soon say bye-bye to all these mysteries when I implement my own copy routines.

[soja]

So I'm trying out version 9.00.0010 for the first time, and XYcopy seems to work great for same-volume copy operations. Let me tell you, it's a breath of fresh air. However, when I copy (or move) across volumes, I get the old behavior with this message when I try to activate the XYplorer window during the copy:

XYplorer: An action cannot be completed because a component () is not responding. Chose "Switch To" to activate the component and correct the problem. <Switch To...> <Retry>

I thought it might have had to do with the fact that my volume is mounted to a folder (and not using a drive letter), but I subst'ed a new drive letter and retried, with the same results.

I'm running Windows 7.

EDIT: Actually, after further testing, this doesn't seem to be a cross-volume issue at all. The issue manifests itself when copying or moving (thought it's less noticeable) directly to/from the desktop. (I'm referring to the shell desktop as opposed to the XYplorer implementation of the Desktop folder.) An easy way to reproduce is simply to CTRL+Drag a large file to the desktop from XYplorer.

I suppose this might have to do with copying to a virtual folder. I haven't tested with another virtual folder yet, but it sounds like dealing with them is going to be a pain.

[admin]

So I'm trying out version 9.00.0010 for the first time, and XYcopy seems to work great for same-volume copy operations. Let me tell you, it's a breath of fresh air. However, when I copy (or move) across volumes, I get the old behavior with this message when I try to activate the XYplorer window during the copy:

XYplorer: An action cannot be completed because a component () is not responding. Chose "Switch To" to activate the component and correct the problem. <Switch To...> <Retry>

I thought it might have had to do with the fact that my volume is mounted to a folder (and not using a drive letter), but I subst'ed a new drive letter and retried, with the same results.

I'm running Windows 7.

EDIT: Actually, after further testing, this doesn't seem to be a cross-volume issue at all. The issue manifests itself when copying or moving (thought it's less noticeable) directly to/from the desktop. (I'm referring to the shell desktop as opposed to the XYplorer implementation of the Desktop folder.) An easy way to reproduce is simply to CTRL+Drag a large file to the desktop from XYplorer.

I suppose this might have to do with copying to a virtual folder. I haven't tested with another virtual folder yet, but it sounds like dealing with them is going to be a pain.

Do you get the same problem with right-mouse dragging to the desktop (and then selecting option from context menu)?