Floating toolbars seem to have problems in Beta 6 that weren't there in Beta 5. I found the problems on my PC (Windows 7 Pro), but I had been fiddling with the DOpus installation, so I have just checked them on my notebook (Windows 7 Home Premium) immediately after updating from Beta 5, which I checked did not have the problems.
On my PC, when I edit a button on a floating toolbar by Alt+RightClick, the edit is not saved. On my Notebook, I could only try this once because after that the panel with the button's code flashes and disappears immediately. This flashing also happens on the PC sometimes with some buttons — in fact, it's happening all the time right now.
As a workaround, I can edit a button by switching on its toolbar as a non-floating toolbar. After this, the button is changed on the floating toolbar as well. (The buttons work, by the way, both by clicking and by accelerator key).
On both machines, with a toolbar on ("Keep on top - - > Optus only", position locked or unlocked), the toolbar disappears with Alt+RightClick on a button on some other toolbar, when I turn on the other floating toolbar, when a button on a non-floating toolbar is rightclicked, and when the DOpus icon in the top left is pressed. These things didn't happen with Beta 5.
The commands for the hotkeys that turn on my two main floating toolbars are:
Toolbar NAME="@LaunchX" STATE=floatactive TOGGLE AutoClose
Toolbar NAME="@Recalculate" STATE=floatactive TOGGLE AutoClose
In beta 6, combining STATE=floatactive and AUTOCLOSE now makes the toolbar close if it loses focus, i.e. if you click anywhere outside of the toolbar.
This is so you get something which is more like a pop-up menu.
Previously, such a toolbar behaved like a pop-up menu (closing automatically) if you chose an item on it, but if you clicked outside of it nothing happened, and you thus had to be close it manually via some other method if you opened it and then changed your mind.
Thanks, Leo. I didn't know that changes had been made to the floating toolbar commands. There are still questions about the behaviour of floating toolbars, however.
Most importantly, I can't edit the buttons on my floating toolbars, because when I try to save them, the old version is saved and the editing is lost. (Well, I can edit them using a work-around if I first turn on the floating toolbar as a non-floating toolbar, but that's pretty clumsy, because the toolbars disappear off the screen.) This behaviour is surely not intended.
The previous point is just about irrelevant now because mostly I can't even Alt+RightClick or Alt+LeftClick on the button — the code for the button flashes up and disappears immediately. This also doesn't seem intended.
There's no mention of command changes to floating toolbars in the notes to Beta 6, nor, as far as I can see, as yet in the Help files, which is of course to be expected in a beta process. What settings do I apply to get the previous behaviour, which is very convenient when editing because it allows one, or two, floating toolbars to remain open in their original positions when editing? (I don't need pop-up behaviour because my hotkeys are toggles, and I can just press them again on the odd occasion that I change my mind.)
Open the toolbar without AUTOCLOSE and you can still edit it. It can still be floating.
We may need to make some tweaks to improve this, e.g. disable autoclose if Customise is invoked, or disable editing of autoclose toolbars (the same as real context menus cannot be edited directly).
Thanks, Leo. I've temporarily deleted AutoClose from the hotkeys invoking the two toolbars. Two remarks:
Ever since AutoClose was added to DOpus11, the old commands for closing a toolbar no longer work, and the Help files therefore need attention. I have a button labelled "Close Toolbar" at the bottom of each floating toolbar, but neither
Toolbar Close=*This nor Toolbar @LaunchX Close
work any more. The command that does work is the same command that now (after deleting AutoClose) invokes the floating toolbar:
Toolbar @LaunchX State=floatactive Toggle (or Close)
Many of my buttons call a user-defined command sequence, to which I can easily add this line. But many do not, so the changed definition of AutoClose will be a real nuisance. The Beta 1–5 version of AutoClose is what I want because it's very simple to use.
Your remark " . . . disable autoclose if Customise is invoked . . . " seems a far better suggestion than "disabling editing of autoclose toolbars", which would be a thundering nuisance. But this would still not solve the proglem of wanting to have two floating toolbars open at once when editing, which was possible in Beta 5. I'm much happier with the old setup.
What has always been needed is a way to invoke a floating toolbar after entering Customise mode. In all versions, if one forgets that the button to be edited is on a floating toolbar, one has had to exit Customise mode, invoke the floating toolbar, then re-enter Customise mode.
That command is wrong. The CLOSE argument doesn't take a toolbar name. This will work instead:
Toolbar CLOSE NAME=*This
Since NAME is the default argument, you can also use:
Toolbar *This CLOSE
Yes, if using a toolbar's name (rather than the special "*This" name), you have to specify that you want to close the floating version, since you can have the same toolbar open as both floating non-floating now.
It is being updated through the beta period and you should expect parts of it to still be out of date. (This is mentioned at the top of the release notes.) But it's also good for us to be reminded of things like this command change, as we could easily overlook them while updating the manual, so pointing things like that out is still useful & welcome.
Is this just because of issues with Customize, or something else? We can probably make Customize work better, and I think aside from the Customize issues the beta 6 AutoClose behaviour is much better and finally provides what people have been asking for for a long time (the ability to open toolbars as pop-up menus).
Nothing stops you turning on and floating toolbars while in Customize mode, using the Customize dialog to turn on the toolbar and the right-click menu on the toolbar to float it. (Or you can shift+click a button which opens the toolbar, since that lets you run buttons while in Customize mode.)
Leo and Jon, thanks very much for all that detail, which makes things much clearer. I am painfully aware that misunderstandings by users are an unavoidable nuisance in a beta process, but despite all my misunderstandings, I hope that my remarks are constructive.
You are right. Apart from unfamiliarity, my only problem is with Customise.
The most important and convenient functionality with customising floating toolbars is:
ACTION: Alt+RightClick on any button on the toolbar.
EFFECT: (As I reported yesterday, this doesn't work at the moment.)
DOpus enters Customise mode, and
The editing box for the button appears (and works), and
The floating toolbar stays on, so that typically several buttons can be edited in the one go, or buttons moved around within the toolbar or between toolbars.
If this worked properly, there would be no real need for a floating toolbar not to close when Customise is invoked by a button, because Alt+RightClick on any toolbar button would be the standard method of invoking Customise with the toolbar open.
[quote] * From Leo: [In Customise mode] you can shift+click a button which opens the toolbar . . .
From Jon: There's also a button in Customize to float the toolbar directly . . .
[/quote]
I've now put AutoClose back into my floating toolbar commands, to make them:
Toolbar Name="@LaunchX" State=FloatActive Toggle AutoClose
Following Leo's remark, I've placed buttons on one of my non-floating toolbar menus with the same open-floating-toolbar commands as my hotkeys. At the moment, however, this method doesn't work:
— Enter Customise mode by a button.
— Shift+LeftClick on the "@LaunchX Floating Toolbar" button: The toolbar comes up.
— Alt+LeftClick on a button on the toolbar: The editing box flashes for an instant, then it and the toolbar both disappear. Not good.
The button in Customise (or Alt+A) is great, and I can report that this does allow editing of the buttons on the toolbar. Thanks, Jon, I didn't know that this functionality was there.
I hope this all helps, and thanks for clearing up my misunderstanding of the commands to close a toolbar, and for dealing with laymen.
Reporting: All now seems OK with the floating toolbars in Beta 7. Thank you very much. (The fixes were not mentioned in the Beta 7 Release History.) Specifically:
Alt+ RightClick can edit a floating-toolbar button, and the editing is now saved.
The previous flashing behaviour is not occurring.
When I press Alt+RightClick to edit a button on the floating toolbar, the floating toolbar stays on as DOpus enters Customise mode.
Hello. I'm having an issue where my floating auto-hide toolbar often randomly disappears & the only way to get it back is to exit/restart Opus, sometimes multiple times. To say that this is frustrating is an understatement. This is occurring in Opus 12, build 7655, 64 bit Windows 10. If someone can suggest a fix, I'd be grateful. TIA!
Windows seems to get confused about docked appbars at times (and almost nothing else uses them so there's probably no hope the OS will ever be fixed).
I've found that toggling the toolbar off and back on usually fixes things when they go wrong. (Sometimes moving the taskbar somewhere else and then back also fixes things.)
I do that via a system-wide hotkey I've bound to Alt + ` which runs this:
True @ Windows confusion about docked app bars. I solved the problem by turning off auto hide, docking the toolbar above the taskbar & making the icons small rather than large. I can't seem to find the option to turn on auto hide in the new above-taskbar position but, in the meantime, it works (and the toolbar no longer goes arbitrarily missing). Thanks!