TFT-LCD AREA USAGE

[NeftaliLoya]

Hello Mr. Azevedo... I used your menu library about 3 years ago and It amazed all of those who did see the results. Back then, I used a TFT_HX8357 LCD with a resolution of 480*320 pixels and I used Bodmer´s drivers to control it. At that time, none of your examples was targeted for this type of TFT-LCD, therefore, I ended up asking for your support on how to use your code on that specific piece of hardware. As a result of your swift and effective modifications, the code was a success and you included the XH8357 example in your menu package, along with a reference to Bodmer's drivers.

Now, I used your library again but with a different TFT-LCD that uses AdafruitGfx library and MCUFRIEND_kvb drivers. All I had todo was to follow your adafruitGfx/tft/tft.ino example, replace the Adafruit_ST7735.h library with MCUFRIEND_kbv.h library and your code started doing its magic almost seamlessly. I just threw in a few tweaks here and there to compensate for the changes brought in by the differences between the Adafruit_ST7735.h and the MCUFRIEND_kbv.h libraries and I was up and flying at no time.

As I have been filling your code´s macro structures with data related to the application for which I decided to use it, I did notice a major change in the way in which your code shows the data within the whole display's area. The first time I used it, the navigation through the menu's structure was such that it allowed me to include 40-characters-wide text strings. Best of all, the selection of a sub-menu, used to append the sub-menu choices right underneath the parent menu choice, so to speak.

With your new approach, your code divides the displaying screen into two horizontal halves and displays the parent menus on the left portion half and the child sub-menus on the right. At first glance, this feature seemed to be an extraordinary improvement to the code; nevertheless, in a real application, its drawbacks outnumber the aesthetic benefits of the improvement because of the following reasons: a).- This divided-screen approach limits the length of the text strings to be shown on the screen. Depending of your settings, a democratic scenario of half and half yields 20 characters for the parent menu and another 20 for the child sub-menus. b).- Of course, you can always split the screen vertically by modifying the code from

MENU_OUTPUTS(out,MAX_DEPTH
  ,ADAGFX_OUT(tft,colors,6*textScale,9*textScale,{0,0,40,8},{0,9,40,8})
  ,SERIAL_OUT(Serial)
);

to

MENU_OUTPUTS(out,MAX_DEPTH
  ,ADAGFX_OUT(tft,colors,6*textScale,9*textScale,{0,0,40,8},{0,9,40,8})
  ,SERIAL_OUT(Serial)
);

so you gain access to the whole screen's width to display 40-characters wide text screens, at a text scale of 2, for parent menus and for child-submenus alike. Despite offering a solution to the previously mentioned 20-characters limitation, the vertical segregation created by this alternative makes the menu navigation a bit confusing for the final user of the device hosting your code. Besides, once you enter into a sub-menu, the parent menu on the top portion of the screen just remains there without offering a substantial benefit. Even the cursor's highlight-effect is lost from within the selected parent menu-choice once you enter into a sub-menu in the lower portion of the screen.

On my previous use of your library, any choice selection from within any parent menu would append the selected sub-menu choices right underneath the recently selected parent menu choice. This menu navigation was very simple and effective because the user always knew where he/she was within the menu's overall structure. The following example illustrates what I'm striving to say:

MENU 1 MENU 1.1 MENU 1.2 MENU 1.2.1 MENU 1.2.1.1 MENU 1.2.1.1.1 Your code would append every selected sub.menu underneath its parent choice and so on...

With that said, can you please point me in the right direction on what to do so the code doesn´t split the screen in two. And better yet, can you please tell me what to do to append any selected sub-menu underneith its parent choice?

The code that appends the selected child sub-menu choice underneath its parent choice was something like this:

//  Define output devices for displaying the menu text...
idx_t serialTops[MAX_DEPTH]={0};
serialOut outSerial(Serial,serialTops);

constMEM panel panels[] MEMMODE={{0,0,480/fontW,320/fontH}}; //  TFT-LCD and FONTS width //and height. 480 x 320 TFT, 10 x 16 FONTS 
navNode* nodes[sizeof(panels)/sizeof(panel)]; //  navNodes to store navigation status.
panelsList pList(panels,nodes,1); //  a list of panels and nodes.
idx_t gfxTops[MAX_DEPTH]={0}; //  
tftHX8257Out tftOut(tft,colors,gfxTops,pList,fontW,fontH); //  

THE CODE THAT DOES THE SCREENSPLITTING GOES SOMETHING LIKE THIS:

#define MAX_DEPTH 5
#define textScale 2

// ,ADAGFX_OUT(tft,colors,6*textScale,9*textScale,{0,0,40,17},{19,7,40,10})
MENU_OUTPUTS(out,MAX_DEPTH
  ,ADAGFX_OUT(tft,colors,6*textScale,9*textScale,{0,0,40,8},{0,9,40,8})
  ,SERIAL_OUT(Serial)
);

NAVROOT(nav,mainMenu,MAX_DEPTH,in,out);
```c++

[neu-rah]

Hi @NeftaliLoya

the 2 halves division is because of this:

ADAGFX_OUT(tft,colors,6textScale,9textScale,{0,0,40,8},{0,9,40,8})

The example you picked up also demonstrates the use of panels, on that example 2 panels {0,0,40,8},{0,9,40,8}, just remove them and make it a single panel covering all screen.

I'm not sure if I follow you all the way, so please try removing a panel and let me know the result...

thanks!

[NeftaliLoya]

Thanks for the swift reply! I removed the second panel and the screen splitting disappeared. Thanks! Let´s have a beer and drink to your code's success!