Design considerations for configuration menu on embedded system

Question

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.

Answer 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.