I was a user of Xplorer² alpha for a while and i've just downloaded the Pro release. I must say it has never been so great, BUT there's always (for me at least) a major problem (as i've wrote it here a few time ago).
Here it is : When i try to delete a folder (empty or not) directly in the tree pan AND if this folder is active in one of the two pans i receive an error message saying something lihe this (it's a translation) :
"sharing violation. source or destination file is maybe in used"
Xplorer² is the only appz which handle the file at that time, i'm sure of it.
I think it's a pitty (for me) because i use always this way to delete folder in windows explorer (w2k or winXP) without problem and it's why i saddly don't use Xplorer² anymore 'cause even with all the very good features i get frustrated all the time.
Thanks
Oh ! I think too : it could be nice to have a "undo" feature (with some limitations) as in Win Explorer.
Problem deleting a folder when it is active (Again)
Moderators: fgagnon, nikos, Site Mods
please see http://netez.com/xplorer2/x2faq.htm#B3
nikos,
This limitation annoys (bugs) me too. While I have trained myself to accept it, I still will occasionally do the intuitive thing and try to delete a folder from the tree pane. Of course when that doesn't work, I go back to the active pane, go up a level, select the folder and then delete it successfully.
But that's extra clicks.
This has come up often enough to have an FAQ, but in my mind it doesn't justify requiring users to be aware of the open pane vs. going ahead with such a frequently occuring intuitive action.
While you can't do anything about another app having a folder locked, it should be straightforward for you to check whether the folder to be deleted is being displayed in one of the x2 panes. If so, you could raise it up a level, and then proceed with the delete action.
This limitation annoys (bugs) me too. While I have trained myself to accept it, I still will occasionally do the intuitive thing and try to delete a folder from the tree pane. Of course when that doesn't work, I go back to the active pane, go up a level, select the folder and then delete it successfully.
But that's extra clicks.
This has come up often enough to have an FAQ, but in my mind it doesn't justify requiring users to be aware of the open pane vs. going ahead with such a frequently occuring intuitive action.
While you can't do anything about another app having a folder locked, it should be straightforward for you to check whether the folder to be deleted is being displayed in one of the x2 panes. If so, you could raise it up a level, and then proceed with the delete action.
Deleting from tree (to recycle bin) works for these cases
* Folder is open in inactive pane
* Folder is item in either pane (or neither)
but not for the case I hit most commonly:
* folder is open in active pane
Note Tree options for above s/b --
UNchecked for Single click to change folder...
(else, folder quickly becomes open in active pane, becoming the case which doesn't work)
* Folder is open in inactive pane
* Folder is item in either pane (or neither)
but not for the case I hit most commonly:
* folder is open in active pane
Note Tree options for above s/b --
UNchecked for Single click to change folder...
(else, folder quickly becomes open in active pane, becoming the case which doesn't work)
this exactly demonstrates my point
if you are trying to delete the active folder, then you've only got yourself to blame
the active folder is always the "current directory" (that's why it can't even go in the bin).
that's how you can execute commands with various $N etc tokens and it works without path info
there would be an extraordinary effort on my part to cancel all that whenever there was a delete request
as far as single click activation is concerned, the only workaround is to right-click and pick delete from the context menu
if you are trying to delete the active folder, then you've only got yourself to blame
the active folder is always the "current directory" (that's why it can't even go in the bin).
that's how you can execute commands with various $N etc tokens and it works without path info
there would be an extraordinary effort on my part to cancel all that whenever there was a delete request
as far as single click activation is concerned, the only workaround is to right-click and pick delete from the context menu
I wasn't suggesting it would be easy to implement ...
only that it would be helpful for users
Not knowing the x2 execution heirarchy/nesting(dependencies?) it seems reasonable to suggest adding a test at beginning of a "delete from tree" request to:
first check if folder is the active pane:
If TRUE,
* remember folder to be deleted
* suspend Single click.../hands free operation (if set),
* then change active pane (cwd) to its parent;
* delete intended folder
* reinstate Single click.../hands free operation (if set),
At finish, highlighted item in tree would be parent of deleted folder, and the current working directory.
The above sequence (in my ignorance of actual x2 code structure) would seem to be a valid approach.
only that it would be helpful for users
Not knowing the x2 execution heirarchy/nesting(dependencies?) it seems reasonable to suggest adding a test at beginning of a "delete from tree" request to:
first check if folder is the active pane:
If TRUE,
* remember folder to be deleted
* suspend Single click.../hands free operation (if set),
* then change active pane (cwd) to its parent;
* delete intended folder
* reinstate Single click.../hands free operation (if set),
At finish, highlighted item in tree would be parent of deleted folder, and the current working directory.
The above sequence (in my ignorance of actual x2 code structure) would seem to be a valid approach.
I see you're thinking out the complications of a 99.99% solution ...
... but for the 90% of users who will only have the one dual-pane instance open when trying to delete a folder they have just examined & determined that the contents are of no further value --
you only need to check the current instance.
IMO that would staisfy the grand majority of users and cases.
... but for the 90% of users who will only have the one dual-pane instance open when trying to delete a folder they have just examined & determined that the contents are of no further value --
you only need to check the current instance.
IMO that would staisfy the grand majority of users and cases.
but keep in mind that it isn't just from the tree; it can be from a scrap frame, a selection of folders in the active pane and god knows what else.
i've added this in my list but without any big priority
also i will have to assess just how complicated a programmed workaround would be; if it takes me 3 months to program something that saves the user 0.1 second... that doesn't make too much sense, no?
i've added this in my list but without any big priority
also i will have to assess just how complicated a programmed workaround would be; if it takes me 3 months to program something that saves the user 0.1 second... that doesn't make too much sense, no?
I understand.
but I say again ...
90% of the time, it's just the simple case that irritates.
And I think that's worth addressing.
PS:
... & tho' it may only be 0.1 sec for you to regroup, for me it's:
1. wait 4 seconds for system to display the "Error deleting file or folder" message box
2. exhibit "doh" reaction (0.1 sec)
3. gather senses (1-5 sec's, dep. on curr state of alleged mind)
4. activate parent, select & delete orig folder (2 secs)
5. continue work (in a chastened mode)
Note: sometimes 2.& 3. will be executed before 1. has timed out.
but I say again ...
90% of the time, it's just the simple case that irritates.
And I think that's worth addressing.
PS:
... & tho' it may only be 0.1 sec for you to regroup, for me it's:
1. wait 4 seconds for system to display the "Error deleting file or folder" message box
2. exhibit "doh" reaction (0.1 sec)
3. gather senses (1-5 sec's, dep. on curr state of alleged mind)
4. activate parent, select & delete orig folder (2 secs)
5. continue work (in a chastened mode)
Note: sometimes 2.& 3. will be executed before 1. has timed out.