Modeless progress dialog on WinVista

[kiku]

Hello,

the "File operation progress dialog modeless" doesn't seem to work on Windows Vista Home Premium, the progress dialog always stays on top.

I checked that it works correctly on WinXP, so anyone else experiences this on Windows Vista?

[fishgod]

I'am using Windows Vista Business x64, having the same problem...

Seems there is a differnce between XP- and Vista-WinAPI

[admin]

I'am using Windows Vista Business x64, having the same problem...

Seems there is a differnce between XP- and Vista-WinAPI

Yes, looks like. Guess I have to update the docs on this.

I'm really fed up with these kinds of surprises. How can they break core system functions that work alright since 1995?

Whenever I find the time I will write a native file operation module that will run in its own thread and do the stuff like I want it to get done. It will probably be an independent EXE like TeraCopy, that's called and fed from XY. Let's call it XYCopy... ... but as I said, some other things have higher prio now.

[kiku]

Whenever I find the time I will write a native file operation module that will run in its own thread and do the stuff like I want it to get done. It will probably be an independent EXE like TeraCopy, that's called and fed from XY. Let's call it XYCopy... ... but as I said, some other things have higher prio now.

Looking forward to see XYCopy working because file operations are quite unstable on Windows Vista.
Teracopy does a pretty good job but is not the perfect solution because you cannot copy outside XYplorer (from your Desktop for example) and paste inside XYplorer (or vice-versa), so please have this in mind ...

regards

[jacky]

Whenever I find the time I will write a native file operation module that will run in its own thread and do the stuff like I want it to get done. It will probably be an independent EXE like TeraCopy, that's called and fed from XY. Let's call it XYCopy... ... but as I said, some other things have higher prio now.

Or, instead of that or as a first step towards that if you want, what about this idea, why I believe would be pretty cool for XY and for us users, and would require less work and time from your part.

How about adding support from potentially any external app as file operations (move/copy(/delete?) handler ?!

Here's how it could work, based on my little dreams from here :

- New INI settings, e.g. CopyHandler=MyHandler (same with MoveHandler (and DeleteHandler?))
- Then on startup XY would look for a file MyHandler.ini in <xypath> (or <xydata>?) which should contain a section [XYplorer] with a few settings. Some optional, some required, starting with the path to the app to be used (support of relative syntax here, so it can remain 100% portable!) Other settings would be the command line, which could be defaulted to something like

Code: Select all

copy "<source>" "<dest>"

- If no INI file, missing setting or app not found, XY informs user and default to the Shell. Then, a new menu somewhere to "Refresh File Operations Handlers" would be nice.
- From this point on, whenever XY needs to copy/move/delete something, it does so launching that app/handler instead of using the Shell

Why would this be awesome ? Because you don't have to write your own handler, yet one could use the app of his choice to handle all file op directly from within XY. I've said it many times, Microsoft implementation if pretty awful, yet I still use it. Why? Because I don't want a script to use TeraCopy or whatever other handler is available out there, because then I can't use all of the great XY features I use everyday, such as Copy Here As, Move Into New Subfolder, simple copy/paste, (right)drag&drop (I mean XY's unique features here, I don't care for added items on the shell ctxt menu), etc

That's why I only have SuperCopier myself (it can hook and "take over" Windows handler automatically), but alas it's buggy and doesn't support XY's features sadly (eg. instead of "Move Here As" it moves into a new subfolder by that name ), so I only activate it on occasion when I know I won't use such features and will move/copy lots of files (and/or big ones, or want error handling support)

But with this system, no more need to use a script or anything : the handler we chose would be "directly" embedded and used from within XY every single time, all the time, thus with a full support of each & every of the addictive XY features. Hell, with the a Delete Handler XY could now "permanently delete" all your files all the time !

I truly believe this would be a wonderful addition to XY, and could also be a way to promote it a little maybe (as TeraCopy users could point out how when using XY it's fully integrated), and because you only launch an external app, I don't think there's any risk to affect XY's stability.

The only downside might be that if you launch the app and forget about it, the automatic "select on paste" feature wouldn't work anymore I think, which would suck. But in all honesty, I'm willing to give up that one if I get all the others !

What do you think about that ?

[admin]

Whenever I find the time I will write a native file operation module that will run in its own thread and do the stuff like I want it to get done. It will probably be an independent EXE like TeraCopy, that's called and fed from XY. Let's call it XYCopy... ... but as I said, some other things have higher prio now.

Or, instead of that or as a first step towards that if you want, what about this idea, why I believe would be pretty cool for XY and for us users, and would require less work and time from your part.

How about adding support from potentially any external app as file operations (move/copy(/delete?) handler ?!

Here's how it could work, based on my little dreams from here :

- New INI settings, e.g. CopyHandler=MyHandler (same with MoveHandler (and DeleteHandler?))
- Then on startup XY would look for a file MyHandler.ini in <xypath> (or <xydata>?) which should contain a section [XYplorer] with a few settings. Some optional, some required, starting with the path to the app to be used (support of relative syntax here, so it can remain 100% portable!) Other settings would be the command line, which could be defaulted to something like

Code: Select all

copy "<source>" "<dest>"

- If no INI file, missing setting or app not found, XY informs user and default to the Shell. Then, a new menu somewhere to "Refresh File Operations Handlers" would be nice.
- From this point on, whenever XY needs to copy/move/delete something, it does so launching that app/handler instead of using the Shell

Why would this be awesome ? Because you don't have to write your own handler, yet one could use the app of his choice to handle all file op directly from within XY. I've said it many times, Microsoft implementation if pretty awful, yet I still use it. Why? Because I don't want a script to use TeraCopy or whatever other handler is available out there, because then I can't use all of the great XY features I use everyday, such as Copy Here As, Move Into New Subfolder, simple copy/paste, (right)drag&drop (I mean XY's unique features here, I don't care for added items on the shell ctxt menu), etc

That's why I only have SuperCopier myself (it can hook and "take over" Windows handler automatically), but alas it's buggy and doesn't support XY's features sadly (eg. instead of "Move Here As" it moves into a new subfolder by that name ), so I only activate it on occasion when I know I won't use such features and will move/copy lots of files (and/or big ones, or want error handling support)

But with this system, no more need to use a script or anything : the handler we chose would be "directly" embedded and used from within XY every single time, all the time, thus with a full support of each & every of the addictive XY features. Hell, with the a Delete Handler XY could now "permanently delete" all your files all the time !

I truly believe this would be a wonderful addition to XY, and could also be a way to promote it a little maybe (as TeraCopy users could point out how when using XY it's fully integrated), and because you only launch an external app, I don't think there's any risk to affect XY's stability.

The only downside might be that if you launch the app and forget about it, the automatic "select on paste" feature wouldn't work anymore I think, which would suck. But in all honesty, I'm willing to give up that one if I get all the others !

What do you think about that ?

GULP! Sounds great, although it's a little bit embarassing for a file manager to outsource basic file operations... Bump this for 7.70!

[jacky]

GULP!

Damn, he didn't read my post again!

Sounds great, although it's a little bit embarassing for a file manager to outsource basic file operations... Bump this for 7.70!

Well, or you could ask what's more embarrassing : allow to outsource basic file operations to good apps, or rely on a crappy implementation (which is also outsourcing, since XY doesn't do it itself anyways) just because it's the "default" OS one...

Ok, I give you a few weeks and I'll bump this

[admin]

How about adding support from potentially any external app as file operations (move/copy(/delete?) handler ?!

Here's how it could work, based on my little dreams from here :

- New INI settings, e.g. CopyHandler=MyHandler (same with MoveHandler (and DeleteHandler?))
- Then on startup XY would look for a file MyHandler.ini in <xypath> (or <xydata>?) which should contain a section [XYplorer] with a few settings. Some optional, some required, starting with the path to the app to be used (support of relative syntax here, so it can remain 100% portable!) Other settings would be the command line, which could be defaulted to something like

Code: Select all

copy "<source>" "<dest>"

Can you give an example how this would work for TeraCopy? As I understood it loads another INI file via command line that contains the details of the Copy job. So how should MyHandler.ini look like to make TeraCopy work?

[jacky]

Can you give an example how this would work for TeraCopy? As I understood it loads another INI file via command line that contains the details of the Copy job. So how should MyHandler.ini look like to make TeraCopy work?

Well, no I think TeraCopy supports this syntax:

Code: Select all

TeraCopy copy d:\sourcefile.ext e:\dest-folder

Though of course, if XY supported a param say <filelist> on the command line (that we can define on TeraCopy's handler.ini) and, when present, it would create a temporary file with the list of all path/names of items, and pass the path/name of that file on the command line, then that'd be even better for sure.