XYplorer Beta Club

There is an unintentional way to overwrite the toolbar.

Set it to this (or just open a new instance):
Scrollable toolbar=OFF
Allow button set switching=ON
You see Toolbar 1 with the icons.

Open "Customize toolbar...", dialog appears. Use the wheel and change the toolbar on the main window once, so you will see Toolbar 2 (main menu text items), then click on the "OK" button in the Customize toolbar dialog. The toolbar will change to icons, and the wheel doesn't have apparent effect anymore, it always shows icons. The status bar helped me to figure out, that switching by wheel still worked, but Toolbar 1 overwrote Toolbar 2.

LittleBiG wrote: ↑11 Feb 2022 20:51 Open "Customize toolbar...", dialog appears. Use the wheel and change the toolbar on the main window once, so you will see Toolbar 2 (main menu text items), then click on the "OK" button in the Customize toolbar dialog...

You cannot wheel the toolbar while the Customize Toolbar dialog is up. Or can you?

admin wrote: ↑12 Feb 2022 11:54 You cannot wheel the toolbar while the Customize Toolbar dialog is up. Or can you?

Yes you can. It kind of surprised me.

Shocking. Definitely not possible in Win8.1.
I'll fix that.

The fix of making the main form not react from all modal dialogs (such as all the scripting dialogs too) is a big loss of functionality for me, I often have a dialog open and want to scroll the list pane (usually horizontally), now that is not possible anymore, is there any chance you can limit the scope to just while the Customize Toolbar dialog is open?

Ok. That's a drastic change from Win8 to Win10. But alright, I'll take back the "fix" and declare the "bug" in this thread as a "feature" ("in Win10 and higher you can duplicate button sets").

No, it is not a feature this way, it is a bug. While the Customize toolbar dialog is open, an accidental wheel movement is enough to overwrite the toolbar set silently and there is a chance that you won't notice it only after it is already saved. (I had to use a backup to restore it actually.)
Please make an effort to turn it into a real feature then. If the OK button is pressed, check if the edited and the actually shown toolbar are the same. If not, show a confirmation question like: "Are you sure to overwrite button set 2 with button set 1?"

Come on, there are a thousand ways where an accidental wheel movement can have far worse consequences. If Win10 gives up the concept of modality (still not sure if that's a bug) I'm not going to sit down and fix that all over the place.

admin wrote: ↑14 Feb 2022 16:05If Win10 gives up the concept of modality (still not sure if that's a bug)

Maybe you misunderstood me. I don't consider this a bug, it is the way how Win 10 works now. But something overwritten by XY without a possibility of cancelling is a real concern. And mainly because it is NOT foreseeable. Who could expect that you are editing the toolbar set 1 and your changes will be saved to another toolbar set by silently overwriting it regardles how you scrolled your wheel? The dialog title says: Custom toolbar - Button Set #1. And clicking on OK will save it to another toolbar leaving button set #1 intact? Nonsense. On pressing button OK, the change should be saved to the very toolbar I have just edited and was shown by the dialog title.

Comment 2:
And yes, the scrolling in the background can be a feature. LIke I am editing button set #1 and I am not sure if the button I am about to add is already in an other button set, so I can scroll the sets through quickly without leaving the editor of set #1. So not the scrolling itself is the bug here.

To avoid this problem, could the Customize Toolbar... dialog be updated to indicate the toolbar set change or possibly have a warning message pop up if/when someone inadvertently changes it by CKS or scrolling. Maybe that would be preferrable to disabling background scrolling? Users certainly shouldn't be changing the toolbar set on purpose after bringing up the Customize toolbar dialog.

EDIT: Another option might be for XY to lock to the Customize Toolbar... dialog to the toolbar that was on display when it was invoked so any scrolling or toolbar set changes are ignored while the Customize Toolbar... dialog is displayed.

klownboy wrote: ↑14 Feb 2022 17:56 EDIT: Another option might be for XY to lock to the Customize Toolbar... dialog to the toolbar that was on display when it was invoked so any scrolling or toolbar set changes are ignored while the Customize Toolbar... dialog is displayed.

I went that way. I agree it was a bug.

Tested and working good for me.

klownboy wrote: ↑15 Feb 2022 14:39 Tested and working good for me.

Yes, I can also confirm it.