Dynamic Menu workaround

[pmcculey]

I'm trying a workaround for dynamic menus where I reserve 10 menu item slots. The output is not as I want it to say the least. The minimalist code is attached: MinMenuTest.zip

Running the file (compiled for MEGA2650) yields the following output:

1. (Read from menuitem before changing, OK, this is how the reserved menu item was declared)

2. (Read from menuitem before changing, OK, this is how the reserved menu item was declared)

10. (Read from menuitem before changing, OK, this is how the reserved menu item was declared)

1. 101s, 21ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

Slot 1 loaded #1. 101s, 21ßC (Read back from the menuitem after being written)

2. 102s, 22ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

Slot 2 loaded #2. 102s, 22ßC (Read back from the menuitem after being written)

3. 103s, 23ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

4. 104s, 24ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

5. 105s, 25ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

6. 106s, 26ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

7. 107s, 27ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

8. 108s, 28ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

9. 109s, 29ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

10. 110s, 30ßC (from the 'Serial.println(SlotStr);' statemant after formatting the string with sprintf)

Slot 10 loaded #10. 110s, 30C (Read back from the menuitem after being written)

10. 110s, 30ßC (Not OK)

10. 110s, 30ßC (Not OK)

10. 110s, 30C (OK)

[jonblack]

Thanks for the example. I'll take a look when I get the chance. This will probably be after the next release, which won't include support for serialising the menu system state.

[pmcculey]

This may be less an issue with the Menusystem code & more likely one with how I'm trying to do this.

[jonblack]

That may be so, but if we get this working it becomes a viable option for #20. This is a kind of object pool for dynamic menus, which might be a useful way to get around memory fragmentation caused by other approaches.

[pmcculey]

Well hope it helps. I should mention that if I assign a literal string ("test1", "test2" etc. ) to the menu items things work as you would expect. Of course thats no use for what I'm trying to do which is to load stuff from eeprom ultimately into a menuitem string. If you have any questions please let me know....

[pmcculey]

Well I was right about it being something I was doing wrong. Its been a while since I worked on this stuff, so I'm really rusty....

I was passing a pointer to a string to the menuitem.set_name() function. Then I was putting a new value in the string on each iteration of the loop forgetting that previous menuitems still had a pointer to the string which now had a different value! Result was a menu with all the same text. Not much of a menu.

The quick solution is to use several strings declared globally along with StrBuf declared inside the function. After the sprintf, use strcpy in each case statement to create an independent copy of StrBuf in one of the strings declared globally which is then passed to the menuiten.set_name() function. This is a bit wasteful of RAM though & I'm sure a more efficient way can be found to do this, I've just got it working & not tried to optimise anything. I've limited my programmable slots to 5 which should be enough for me.

If you want I can code this up as an example & send it on. It seems to work OK in my application.

[jonblack]

Related to #20. Closing as this is resolved.