If you can print the option to the screen you’re going to have the whole string in memory somwhere anyway, so this is a bit of a non-issue.
The problem with using the index is that then the reaction is bound to the index rather than the actual menu item, so if you reshuffle the menu items then you have to remember to change the code as well.
This is why the menu system in my repo uses function pointers.
It results in more progmem usage than using an index,
but it’s the most flexible option.
In my Minesweeper game I do something between the two,
I have a scoped enumeration that identifies the action to perform,
that way the action is cheap but it also overcomes the issue of having the functionality bound to the index rather than the actual menu item.
So this is for an unrelated project using a different setup?
If so you should have mentioned that sooner, this is an Arduboy site so we always assume people are talking about the Arduboy.
It’s hard to make recommendations without knowing the setup.
For one thing the available pool of APIs will have a big impact on what the code looks like.
(Also technically not being Arduboy related makes this somewhat off-topic.)
Without knowing the specs of the device it’s hard to know how it’s working.
It’s possible that they have a dedicated SD reaching chip or something.
No problem, I’ve had time to refine it.
If you’re more of a hardware person then it might be worth mentioning that one of the potential hardware methods for selecting a byte for read or write is through an N-bit multiplexer (where N is the bit width of the processor’s address size).
So if you think for a 4-to-1 multiplexer you have 2 select lines,
the thing that selects a byte of RAM is essentially the same,
except it has N select lines (in the case of most AVR chips, N is 16).
I don’t know if that’s actually how it works with real hardware,
but that’s the way I discovered when trying to build virtual CPUs in video games that have logic gates.
(Also if none of that makes any sense, don’t worry.)
This code has the advantage of knowing all the text beforehand.
Constructing text ‘on the fly’ is more complicated.
The approach you can take will depend on several factors:
- What rendering API will you have available?
- What’s the spec of the system?
- In particular the amount of RAM, the screen resolution and the CPU speed are going to be important
- Will the file names all be in 8.3 format?
- Is there an upper limit on the size of the file names?
- How much RAM is actually free for use?
- I.e. not in use by a screen buffer.
(Side note: I think it’s a bit strange that this library is using newlines instead of having multiple text entries.)
I think it’s going to look a bit odd because the first comment will be missing some context,
but it’s probably best to put this in the ‘off topic’ area, so I’ll move it anyway.