XYplorer Beta Club

nas8e9 wrote:To eliminate the small possibility that some *combination* of settings causes your problem, could you try it with a default configuration? (The easiest way is to copy XYplorer.exe to an empty folder and run it from there.)

Oh, no! YOU WERE RIGHT!
-easiest way to down-upgrade without losing my setts? Anyone? I mean... Eliminating action.dat would be enough? XYplorer.ini, perhaps? (which probably will leave me with a reconfig situation...)
-strange thing I noticed: when moving TEST folder (which has a file opened) to TEMP, Windows trowed a dialog telling the action couldn't be done due a file being in use. As expected. BUT: folder TEST was still being showed as a TEMP subfolder in XY list but not in tree, clicking on it results in nothing, THAT ACTION WAS NOT LOGGED (previously discussed here and fixed in a previous build, will check later for the references) and when closing the file that was locking the process, moving again TEST into TEMP caused a dialog telling that TEST was already there - "Confirm folder replacement", I guess (native: "Confirmar substituição de pasta") - yes, yes for all, no, cancel.
---
-Suggestion: Don: in a fresh install, if I click on "Open configuration file", XY just tells that the file hasn't be created yet (which is a fact!). Can this be avoided by just creating one on the fly, so newcomers won't bother on what's going on?

GOTCHA!
Problem was: I had CustomDnDMenu=0, so I could have direct access to WinRAR menu instead of scrolling down after it each and every time I un-rar a file (which happens often!).

Fix: set CustomDnDMenu=1.

Don's turn:
1) Now I consider this a bug. Can you please provide a solution for it?
2) Workaround: put that "Shell Context Menu..." option in the middle of the context button (so it'll be easily accessible from top to bottom and vice-versa); else, make submenus for the "Copy/Move/Create" numerous options.

Side note: Used AptEdit's AptDiff to compare "bugged" .ini against a clean one; out of curiosity I tried TotalCommander's "Compare File" or something like that and I realized that it would be impossible to get the job done with TC.
Also my special thanks to nas8e9, whose considerations on the matter led me into the right direction (after MONTHS of not relying on XY's great undo - the reason why I kept apart from XY for years!).

Could please rephrase in whole and handsome sentences what you think is a bug.

Quoting above:

-XY logs for undo: moving files using Panes> Move to Other Pane, also thru CKS; rename operations (even on tree!);
-XY does NOT logs for undo: dragging from pane to pane; dragging from tree to pane; dragging from pane to tree; dragging inside the tree.

I think that should be enough.
I thought it could be OS related, as described in the post (and original post, too). But it's not: now I realize that my Win7 machine was not being affected because I haven't got the time to properly customize XY to my likings as I did in the other 2 machines.

SkyFrontier wrote:Quoting above:

-XY logs for undo: moving files using Panes> Move to Other Pane, also thru CKS; rename operations (even on tree!);
-XY does NOT logs for undo: dragging from pane to pane; dragging from tree to pane; dragging from pane to tree; dragging inside the tree.

I think that should be enough.
I thought it could be OS related, as described in the post (and original post, too). But it's not: now I realize that my Win7 machine was not being affected because I haven't got the time to properly customize XY to my likings as I did in the other 2 machines.

No, it's not enough, because I told you already that this works. Can you give me a way to reproduce the bug?

I'm actually more confused now...

Don responded to your post here:

GOTCHA!
Problem was: I had CustomDnDMenu=0, so I could have direct access to WinRAR menu instead of scrolling down after it each and every time I un-rar a file (which happens often!).

Fix: set CustomDnDMenu=1.

Don's turn:
1) Now I consider this a bug. Can you please provide a solution for it?
2) Workaround: put that "Shell Context Menu..." option in the middle of the context button (so it'll be easily accessible from top to bottom and vice-versa); else, make submenus for the "Copy/Move/Create" numerous options.

Basically, what you seem to be saying is that setting CustomDnDMenu=0 results in file operations not being logged. I sincerely hope I've got question and anwer right so far?

SkyFrontier wrote:Quoting above:

-XY logs for undo: moving files using Panes> Move to Other Pane, also thru CKS; rename operations (even on tree!);
-XY does NOT logs for undo: dragging from pane to pane; dragging from tree to pane; dragging from pane to tree; dragging inside the tree.

I think that should be enough.
I thought it could be OS related, as described in the post (and original post, too). But it's not: now I realize that my Win7 machine was not being affected because I haven't got the time to properly customize XY to my likings as I did in the other 2 machines.

This seems to me to be your original bug report, which you claimed was fixed by the setting above?

Oh, sorry. I thought you overlooked today's post.
Well... just set Voilá. Undo partially logs actions for undo.

Forgot to mention... bug works also on fresh installs!
Thank you for considering to fix this, Don.
And... enjoy your vacations! You deserve them!

SkyFrontier wrote:Oh, sorry. I thought you overlooked today's post.
Well... just set

Code: Select all

CustomDnDMenu=0

Voilá. Undo partially logs actions for undo.

Confirmed: there is no undo for actions triggered from the shell drag'n'drop menu. The problem here is that the whole thing is completely outsourced to the shell; the shell pops the menu and performs the file operations; I don't get any feedback about if and what action has been triggered. No chance for logging an action.

Of course, hardly any sane XY user would use this shell menu when there is the much better XY drag'n'drop menu, IMO one of the best features of all in XY. And those actions can be undone.

Admin:

Of course, hardly any sane XY user would use this shell menu when there is the much better XY drag'n'drop menu, IMO one of the best features of all in XY. And those actions can be undone.

...that's the reason why I'd like to comfortably keep the best of both worlds...

...allow customization of XY context menu? Perhaps? Ability to integrate native shell's entries directly into this custom menu?

SkyFrontier wrote:...allow customization of XY context menu? Perhaps? Ability to integrate native shell's entries directly into this custom menu?

Not directly, but Shell Context Menu is already an item (near the bottom) in XY's menu...

Not that I am lazy, but it's unpleasant to right click (from panel 1), drag into tree, scroll all the way down thru that long menu, select "Custom Shell Menu...", scroll all the way up again and finally get what you want. Not to mention the times when touchpad messes up things and for a reason or another I have to start the whole process all over again.
Multiply that tens of times a day and you'll probably get the picture.
I like, LOVE options - but usability has to come into play in a primary role.
Anyway, I prefer having all undo XY can offer than saving my poor hand a few meters more (while it stands...).
Damn.

Thinking a bit... If the disallowing of custom drag'n'drop seriously compromises the great Undo feature, plus being such thing as "one of the best features of all in XY", and no technical workaround could solve the problem, why not remove (...can't believe I'm saying that...) the "CustomDnDMenu=0" tweak?

Because I said "IMO one of the best features...".