BlackBox Framework Center

Josef Templ wrote:fixed.
The tests had a dependency on the order of menus due to a subtle bug in hotkey handling.
Build http://blackboxframework.org/unstable/i ... a1.706.zip contains the fixes.

- Josef

That works!
-Doug

Josef, how do you suggest to optimize menus structure? Can you include your ideas in that demo?

A nested menu is defined very much like a top-level menu except that its name must start with the character "$". In order to reference such a menu in a menu item, use the name of the nested menu (including the leading "$") as the action string. Menus can be nested at arbitray depth and it is also possible to reference a menu multiply.

I think that needs to be expanded and clarified with examples.

-Doug

DGDanforth wrote: I think that needs to be expanded and clarified with examples.

-Doug

Sure, but before finalizing the docu we should agree on the final format
of nested menus.

Currently it is not possible to have a normal top-level menu that starts with the letter "$"
because $ is used as an indicator that a menu is a nested menu. I think this is not a big problem
but it needs to be agreed on because it is a hard-coded limitation of the possible menu names.

The alternative would be to handle it as in CpcDropDown, where a special type value is used as
an indicator that a menu is not to be displayed in the menu bar. CpcDropDown menus are actually conditional
menus with a type that never appears and therefore the menu is never displayed as a top-level menu.
The possible alternative is shown below. It uses the type "NESTED" to indicate that this menu is a nested menu.
The "$" is still required as the first character of the nested menu name because this is required for recognizing
that the action string of a menu item refers to a nested menu and not to a command.
For migration purposes the type "CpcDropDown.DropDown" could still be supported as an alias of "NESTED".

MENU "$my nested menu" ("NESTED")
..
END

- Josef

How about something like where INCLUDE is replaced by NESTED and that expands to
<StdMenuTool.NestedMenu>NESTED<>
where StdMenuTool.NestedMenu is a new procedure.

Ivan Denisov wrote:Josef, how do you suggest to optimize menus structure? Can you include your ideas in that demo?

Currently I would not change the menu structure at all. This would be outside of this issue.

I have some rough idea for a menu improvement, though, but nothing implemented and not analyzed in detail.
What I can imagine is a concept of extensibility of menus in addition to extending the menu bar.
Currently the only way to get menu items that belong to an extension package is to create a new
menu and if you have many extension packages you get many menus, or you must manually edit the standard menus.

The idea is to support something like "menu extensions", i.e. extending an existing menu with the same
name instead of creating a new one even if it has the same name.
For example "Help": An extension package should be able to add a menu item to the Help menu.
This could also be applied to SQL and COM, which have Help items in their menus.
Another extension package (Srcnav, for example) may want to add a menu item to the Info menu.
But detail problems will arise in particular the question where to insert an extension unless it is simply appended.
It would need a little research how other systems (e.g. Eclipse, NetBeans, Visual Studio) handle menu extensions.

- Josef

If it is possible without big change in the code I would prefer

NESTED "$my nested menu"
..
END

or

NESTEDMENU "$my nested menu"
..
END

Ivan Denisov wrote:If it is possible without big change in the code I would prefer

NESTED "$my nested menu"
..
END

END

That I like.

Josef Templ wrote: Currently it is not possible to have a normal top-level menu that starts with the letter "$"
because $ is used as an indicator that a menu is a nested menu. I think this is not a big problem
but it needs to be agreed on because it is a hard-coded limitation of the possible menu names.

The alternative would be ...

Leave it as it is for version 1.7.x and left the introduction of a new keyword to version 1.8 Then you have the whole freedom to change your mind after working it out.

Josef Templ wrote: The idea is to support something like "menu extensions", i.e. extending an existing menu with the same
name instead of creating a new one even if it has the same name.
For example "Help": An extension package should be able to add a menu item to the Help menu.
This could also be applied to SQL and COM, which have Help items in their menus.
Another extension package (Srcnav, for example) may want to add a menu item to the Info menu.
But detail problems will arise in particular the question where to insert an extension unless it is simply appended.

Simply append it. That should be done for 1.7.x and all the other solutions left for 1.8

- Helmut

DGDanforth wrote:

Ivan Denisov wrote:If it is possible without big change in the code I would prefer

NESTED "$my nested menu"
..
END

END

That I like.

Besides technical problems and complications, this uses a sub-optimal wording.
If you have a procedure in CP nested inside another procedure, is the nested procedure then a
"procedure" or a "nested"?

The simplest way is to leave it as it is, i.e. with the leading "$" as the submenu indicator.
Also "*" is already used as an indicator of special menus, by the way.
As a simple work around when somebody really needs a menu name with a $ as the first character,
it suffices to put the hotkey indicator & in front of it. So there is no real limitation any longer.

The docu has been improved.
See the diffs at http://redmine.blackboxframework.org/pr ... 6471601f48.

- Josef