Dear Maharaja,
till now we haven't used any external tooling to manage menu systems. in the past we developed individual menu system frameworks on behalf of the customers. Our approach was to provide the customer with components, he/she can simply compose together visually in Embedded Wizard by drag-and-drop. From the composition results then the menu structure. I have developed an example demonstrating this approach. May be it helps you to progress? Feel free to modify it to your needs.
http://ask.embedded-wizard.de/?qa=blob&qa_blobid=10348282335125775454
The example demonstrates the idea of how to divide complex menu systems in a 'content' (model-controller) and 'presentation' (view) part.
A.) When you open the example, you will find two units:
- unit Menu contains the implementation of a simple menu framework
- unit Application contains an example of a menu constructed using this framework.
The individual components are described in annotations within the project. Please note also the descriptions I left for the various members as well as the inline comments within the methods.
B.) The most important aspects are:
- A menu is defined by menu-item objects within a menu class.
- There are four prepared menu item classes (SubmenuItem, ToggleItem, ActionItem and ExitItem).
- Every menu-item class has few properties to determine e.g. the caption or the icon to show in the menu.
- You can add more properties to the item classes e.g. additional text, icons, etc.
- You can also modify/enhance how the four item classes appear and behave.
- You can duplicate any item class and implement your own particular special menu items (e.g. an item intended to store a command string, which is sent to a device as soon as the user has activated the item, etc.).
- To define a new menu derive a new class from Menu::Menu.
- In the new class add as many instances of the menu-item classes as you require in the particular menu.
- Please note the order of menu-item instances within the menu class. It corresponds to the order in which the items are presented later on the screen. The order can be reviewed in Inspector.
- The presentation of items is handled by the component Menu::MenuView.
- For this purpose the class Menu::MenuView provides few methods to open/close a menu.
- Menu::MenuView manages the history of currently opened menus so you navigate forth and back through complex hierarchies of menus.
C.) Usage cases:
In the praxis we see 4 possible usage cases how menu systems can be created and managed:
Case 1: Manually at the design time
This is exactly the approach I described above. It is also demonstrated in the attached example:
- For a new menu, you derive a new class from Menu::Menu class.
- Then you feel it with menu-item instances.
- Finally you specify the values for properties of every item (e.g. caption, slot method to call when the item is activated, etc.)
Case 2: Programmatically
This is an approach useful when the content of the menu is dynamic depending on e.g. data received from a device, etc. This is also demonstrated in the attached example. In this case:
- You create first a new instance of the Menu::Menu class. At the moment such menu is still empty.
- Then you create dynamically all the necessary menu item objects.
- You configure the properties of every menu-item object (e.g. its caption, etc.)
- Finally you add the just created menu item objects to the menu by calling its AppendItem() method.
- Please note the order in which the items are displayed on the screen corresponds to the order in which they have been added to the menu.
Case 3: Generating EWU file
Thanks to the separation of content and presentation, the definition of a menu is relatively slim. Every menu is a individual class containing embedded objects - one object for every item. If required, it should be possible to use external tools (e.g. macros running in Excel) to automatically generate such EWU files. A menu within the EWU file looks like this:
class SubMenu : Menu::Menu
{
inherited property Caption = "Sub-Menu 1";
object Menu::ActionItem ActionItem1
{
preset Caption = "Action 1";
}
object Menu::ActionItem ActionItem2
{
preset Caption = "Action 2";
}
...
object Menu::ExitItem ExitItem
{
preset Caption = "EXIT";
}
}
Case 4: Interpreting Menu-description from files at the runtime.
The last case addresses the approach to implement an interpreter, which at runtime reads menu configuration files and depending on the contents found there creates menus and fills these with menu-items (as describe in case 2).
So far the possible cases.
From my point of view, the case 1 is the simplest one. Sure, you have to implement every menu manually. But compared with the effort to e.g. implement an Excel --> EWU converter (case 3) or an config-file interpreter (case 4), it seems for me less intensive.
Important is, that you have adapted the menu framework to your particular project requirements. In its current version it is just a example common for the typical menu applications.
Last but not least, once you have the various basic components implemented, you can add your own templates for them to the Gallery. In this manner you can conveniently drag-and-drop the components from the Gallery to the Composer.
What do you think? Does the example help you further?
Best regards
Paul Banach
