Toolbox help, please

I’m writing a Toolbox app. It’s all going spiffingly except for one small detail. There’s an icon bar menu, and it has a submenu from one item. The submenu in turn has a submenu of sorts; going right from any entry opens up a window (four display fields plus three action buttons) relating to the submenu item. The window is opened with menu semantics. It all works exactly as it should when clicking any of the action buttons with Select – the entire menu tree closes. Clicking with Adjust, however, keeps the first two menu levels open, but the window closes. It’s not Style Guide compliant.

I think I’ve read the toolbox manual in sufficient detail that there’s nothing obvious jumping out to me that I could do differently to keep the window open on Adjust clicks.

Any help would be appreciated.

On second thoughts, I think I’m asking something impossible of the Toolbox. Clicking two of the buttons would alter the menu contents, so it’s like rebuilding a tower under me.

I think clicking Adjust on any of them will just have to close the entire menu tree.

Not a toolbox user, but what you’re describing is easily ‘got wrong’ using the Wimp SWIs too. It’s caused by a combination of menu structure and MenuWarning message.

However, that should only be relevant when clicking in a menu entry – clicking in a dialog that is part of a menu structure does not cause the Wimp to automatically close the menu, regardless of button.

So the toolbox is deliberately closing the menu on the dialog click, and then attempting to reopen it again (which will not work because it does not know to open that dialog again – because the menu structure has not been updated with the dialog handle).

As I said, I’m not a toolbox user, but I suspect there will be a way of marking the dialog as a menu dialog rather than a normal window… or the menu can have the dialog reference permanently attached as well as the MenuWarning bit… or the toolbox is, as I’ve always thought, a bit poo. I hope I’m wrong about that though.

So the toolbox is deliberately closing the menu on the dialog click, and then attempting to reopen it again (which will not work because it does not know to open that dialog again – because the menu structure has not been updated with the dialog handle).

Experiments just now support that explanation. If I even remove or add a tick from/to one of the submenu entries, the dialogue box closes on clicking the action button. (Performing other actions, while leaving the menu contents unchanged, leaves the dialogue box open.)

But I don’t know what you mean by “dialog handle”. Presumably you’re not referring to the ObjectId of the dialog box?

The dialogue box is linked to each of the submenu entries by specifying the template’s name in the “submenu_show” field of each of the submenu entries as I add them. Is there another way to mark it as a menu dialogue? I can’t see any such way in the Toolbox manual.

As I don’t use Toolbox there’s a danger I may mislead, but I seem to get the desired result with this kind of setup:

So the menu items do have a submenu (which will be your dialog) and does reference the dialog in question (show object) but also delivers an event when opening (so you can change the contents of the dialog).

That works fine with Select and Adjust.

That works fine with Select and Adjust.

If I read this correctly, doing something in the dialogue changes the menu, and that’s what causes the problem.

If ticking that option button caused the associated menu entry to be ticked…?

That shouldn’t cause the problem, though it may trigger it. Mapping this back to Wimp SWIs cos I’m oldskool: Changing the menu definition will not affect the menu on screen if it’s still open, so CreateMenu would have to be called on the adjust-click that changed the def. That would kill the dialog unless the submenu pointer contains the dialog handle. Else the code would have to also call CreateSubMenu to ensure the dialog was open. The result might be flickery.

The interesting question and not one I can answer is what does the Toolbox Menu handler do when the menu is modified while open… because it sounds like it’s not putting the actual window handle in the submenu ptr, and is also failing to call CreateSubMenu.

I suppose Dave could manually CreateSubMenu after every Adjust-click that would trigger the problem. i.e.

!q%=FNgetToolboxDialogWindowHandleBySomeMechanism
SYS&400CB,,q%:SYS&400E8,,!q%,q%!4,q%!16

Something like that. Don’t know whether Toolbox will then explode. I don’t use it.

If I read this correctly, doing something in the dialogue changes the menu

That’s definitely true.

and that’s what causes the problem.

That appears to be true. I can do other actions, that don’t alter the menu, as a result of clicking the action button, and the dialogue box remains open correctly. But if I add a tick to, or remove a tick from, an entry in the menu above, as a result of the click on the action button, the dialogue box closes on both Select and Adjust clicks. The same happens if I completely recreate the submenu.

The submenu (immediately above the dialogue box) has to be created programmatically, because it can contain any number of entries. I think what I’ve got is equivalent to what nemo shows in the ResEd screens, because I have:

MenuTemplateEntry Entry = {0};
...
Entry.submenu_event = SubmenuShowPrDetails;
Entry.submenu_show = "PrDetails";
menu_add_entry (0, pr_submenu_id, -2, (char*) &Entry, &new);

The first of those lines is shamelessly copied from the Hyper toolbox example. The penultimate line references the template from which the dialogue box is auto-created.

The submenu_event invokes a function that sets the values of the four display (i.e. text) fields in the dialogue box, and nothing more.

The “Select” action button in the dialogue box that’s giving this trouble, is merely providing an alternative method to select an item – the most direct way is to click on the submenu item. So the simplest way to remain Style Guide compliant in handling the Adjust button is to not have a “Select” action button.

But it’s been an interesting discussion, and I thank nemo and Rick for your contributions. It looks to me like what I’ve found is going to turn out to be a bug in the Toolbox.

The other button in the dialogue box is “Forget”, which will remove this item from the app’s stored choices. That’s akin to sawing off the branch you’re sitting on, so there is at least a reasonable case for not keeping the dialogue box open. In fact it might be more obvious if the entire menu tree were to be no longer displayed, as it would be if the Select mouse button were clicked. I can’t see a Toolbox way to do that, so I think it means a call to Wimp_CreateMenu with R1 = -1.

This is why I don’t use the Toolbox. Sorry I can’t be more helpful.

This is why I don’t use the Toolbox.

You wimp!

I do.