I am not the expert, but I believe that it workls as follows: 1. You have to initialize each item in your list. In menu_App (an example for using a list), you will find that the text of each item is initialized with the names of the available application). The number of items has also to be set. When you are 'ready', you can call LIST_Set(). 2. Then you have to call the LIST_Manager() from your own handler. It will return (-1) as long as no item has been selected. Once an item has been selected, it will retun an integer that matches with the index of this item.
In Menu_App, the list (and the items) are static. For sure it would be much better to build dynamically the list. I believe that you can use the standard memory allocator (malloc/free) in your application. To be confirmed...
I'm able to display a list with items but the LIST_Manager doesn't return anything else then 0 when I tilt the Primer. The list slowly scrolls down and the list is filled with blue lines..
As soon as I press the button, the main App menu is shown so I guess something is wrong.. but what?
And who's responsible for scrolling in the menu with MEMS etc? I assume that's all handled somewhere magically in CircleOs
Everything is managed in list.c. The normal behaviour should be: You change the selection by touching, or with the joystick (tilting vertically should also generate a scroll). It should return -1 until you push on the button, or you double click (MEMS), or you keep a long pressure with the touchscreen on one item. In this situation, it should return the index of the item. We will check with a simple application (we never tested the list called from an application, but we just use it to select the application in CircleOS).
Joystick seems to work when it's set to both Mems+joystick.
Selecting something with the touchscreen is a bit tricky but this might be caused by some calibration issues. I guess it's also possible to catch joystick events?
Another question.. how to dismiss a list and display a new one.. MENU_Quit stops the whole app.
Try to call again LIST_Set with the new list. The list manager is not reentrant and you will reinitialize it.
Note that the background is not saved (neither for the menu, nor for the screen that work on the same principle). We don't have so much memory for keeping an image of the previous screen contents. It would be probably better (above all for lists), to use the whole screen to display information with a larger font.
At the moment, the scrolling of the list is done by software (we don't use the LCD capabilitiy because it works only with one direction (vertical) and we wanted to keep the free rotation... A larger screen will make the scrolling slower. However, we use DMA for scrolling and it could be acceptable...
For a full screen list, I meant that we should modify the source in order to remove the border (useless for a full screen mode). It is not implemented yet.