Is it possible to launch a floating toolbar with a particular button selected?
I am assuming that the buttons are numbered from 1 to n, so that the toolbar command would have an extra argument such as 'Select'. The full command would then be something like:
Toolbar MyBar State=FloatActive Toggle AutoClose Select=4
That command should shade Button 4 to indicate that just pressing Enter will launch it. Otherwise, the arrows can move the selection from there.
(I am wanting something similar to the script command oDlg.defvalue = 4)
Scripts can create simple pop-up menus (see the Dialog.Menu property) which can indicate a default in bold. I'm not sure if it will select that item so you can just push return; normal context menus will do that when opened via the keyboard but I haven't tried it with scripting ones before.
Thanks, Leo. So my failure to find it was because it wasn't there.
There is a bigger problem with the selecting of a button or menu in a floating toolbar --- and in a fixed toolbar. Suppose that I launch a floating toolbar with the command
Toolbar MyBar State=FloatActive Toggle AutoClose
That toolbar launches with nothing selected, and the arrows, with or without Ctrl, Alt or Shift, do not put a cursor on the toolbar.
But if the toolbar has a menu labelled &MyMenu with an accelerator key, then pressing M not only opens the menu, but puts a 'cursor'-like object on the toolbar, and the cursor can be run up and down across menus and buttons using the left and right arrows. The up and down arrows, on a menu, run the cursor up and down its submenu. Enter works like a left-click on the selected item.
If there is no menu with accelerator key on the toolbar, however, the cursor can't be put onto the menu.
If the cursor is run off the top or bottom of a submenu, it cycles. But if it is run up and down a toolbar, it disappears until a menu-accelerator key is pressed again.
Interestingly, a mouse-click certainly opens the menu, but the 'cursor' can not be run up and down the toolbar or the submenu using the arrows.
FEATURE REQUEST:
A floating toolbar, by default, should places a 'cursor' initially on the top item, from where it can be run around using the arrows.
The command Toolbar should have a further argument 'Select' so that, for example, Select=4 places the cursor initially on the 4th item.
The cursor should not be allowed to be run off the top or bottom of the toolbar and disappear. It should cycle, or remain motionless.
A mouse-click on a menu, should work like an accelerator key, and produce a cursor that can be run up and down the toolbar and the submenu.
Points 3 and 4 should apply to fixed toolbars as well.
By the way, this request came from my earlier post Flashing dialogue window in script. I gave up solving the flashing problem in successive dialogues, and I have turned the successive dialogue windows into floating toolbars, which do not flash, and I am using DOpus global variables to carry the necessary information around.
Floating Toolbars really aren't designed to be used as pop-up menus. (That's what pop-up menus are for. :))
Your issue with multiple dialogs from a script would be better solved by having a single dialog that asks for all the needed information at once. There's no reason for it to display floating toolbars that I can see?
Thanks, Leo. One of the things that I really appreciate about DOpus is its flexibility. Very often I have two or three ways of going about something, and I can experiment and choose — and learn in the process. So I will stick with the requests that I made in my previous post, which to a non-techie do look rather straightforward.. (And Point 5 should have included Point 2 in its recommendations for fixed toolbars as well.)
Having said that, however, I confess that despite several attempts. I have still not been able to implement DOpus' more complex dialogues, and so far I have stuck with the old ones. When I get more time, I will address this failure of mine with steely determination, plus a new post if I still can't sort it out.