7

I am working on an embedded system that interfaces with the user with several buttons and a small graphic display.

As a side note: Since I am on an embedded system, I would like to prevent dynamic memory allocation as much as possible. Something like std::vector is not even available.

I need to implement a configuration menu using a classic nested menu structure like this:

Level A Node 1
 -> Level B Node 1
    -> Level C Node 1
 -> Level B Node 2
 -> Level B Node 3
Level A Node 2
Level A Node 3

I am very unsure about the best approach here. I read about several ways to approach something like this like using the Composite Pattern. However, I always bump into something that looked good "on paper" but seems to be a mess to implement.

My general thought is to have something a MenuNode class that knows about its sub-nodes and parent node upon initialization. A Menu class could handle the node navigation and processing. Obviously, every MenuNode has to execute/implement specific behavior like:

  • Report to the Menu what it wants to display (the actual layout / positioning should not be the concern of the MenuNode)
  • React to user input (like a button press to increase/decrease/switch a value)
  • Access the actual value of interest (they reside in a ApplicationSettings class)

What would be the best way to implement this?

  1. Use an (abstract) MenuNode base class and create a sub-class for EVERY menu-node item. During initialization I could provide a pointer to ApplicationSettings or other dependencies it may need. Somehow it feels wrong to create like 10 derived classes where each will be instanced just once.

  2. Use the same MenuNode class for every node and implement functionality through callbacks to free functions. From what I read its pretty common to "couple" free functions with objects. However, it feels like it would over complicate things. For each member there might be, like ReportButtonPress() or something, I would have to provide the callback for the actual implementation during initialization.

  3. I am sure there is something I am overlooking here.

  • 5
    I have done similar menus for embedded using C in the past, and this is the biggest thing I learned from it: Keep menu definition separate from implementation. Use hierarchial text file format (JSON/XML/...) to describe the menu, then use scripting language to convert it to C or C++ data structures. This gives you freedom to change implementation as you please, and ability to preprocess the data to the most efficient form (helps avoiding dynamic memory allocation at runtime). – user694733 Nov 30 '16 at 11:40
1

Go with option 1, create statically one class per UI item to bind input events to actions. This way the implementation will NOT allocate memory at runtime.

If your C++ compiler supports lambda closures, that is a tidy way to bind the input events to actions in your menu setup code.

With everything static code verification tools have a chance of picking up errors.

Ignore suggestions to have a "menu file format" an build your own tools. You aren't in the business of selling menu toolkit libraries, so don't do it.

You say that you have a small graphic display... Is that a graphical (bit-mapped display ?) If you aren't using a GUI toolkit, ask yourself why not? If it just won't fit, fair enough. QT embedded or something lighter might save you a lot of error-prone GUI widget code.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.