When I started with this, I had no idea how this would evolve... Basically, the idea was to add a status bar to all or selected pages of any HMI project. Naturally coded in an optimized way with a minimal consumption of RAM and processor resources. While I was working on that, questions related to a Nextion HMI based menu to allow easier navigation arose in a Nextion related FaceBook user group. That's how and why I continued, adding a menu "hamburger" to the status bar, allowing to display a customizable text based page navigation menu to whatever project. To prevent any memory issues, especially on smaller Nextion HMI displays with 3.5k RAM, I continued making excessive use of GUI commands for this, so that the menu adds only a single transparent overlay page without components to any project, and a simple hotspot component to every page from which the menu could be called. User feedback taught me that this was great, but that the use cases were somewhat limited since the menu and its items were the same on every page. Thus, in the next article, I extended the code to allow adding individual menu items, depending from which page the menu was called, to the "common" list of menu items. But while I was still working on that, new user feedback told me that it would be great to filter out the calling page from the menu, to leave more space for more meaningful items. I promised to do this, and that's the topic of this article.

After adding a toolbar and a static menu to our Nextion HMI, we will add an extension to the latter, today. While it is convenient, not too difficult and, thanks to some of the developer's efforts, not very resource consuming to have a common menu, which means it being identical for all pages, the one or the other application would perhaps be more ergonomic if we hadn't all menu items available on all pages... Thus, having foreseen that, I'll give you the choice today. We'll add a few lines of code to our project and especially another single global text variable to the menu page. This will give us the option to keep all common menu items in the menu page's cfg_menu variable. AND we'll have the option to add individual menu items for each page.

At the end of the last blog article where we saw together how one could (almost) automatically add an animated status bar to each page of a Nextion HMI project, I promised you that it would still evolve by adding a menu to it. When I started developing it, I discovered so many amazing things, and I found ways to optimize several aspects, that it took much more time than foreseen, but finally, here we are! If you didn't already, you really should read the previous article and have a look onto its demo project code, to fully benefit from today's extensions.

The Nextion status bar - advanced programming The idea... ...which I had in mind was to create a status bar which would - similar to the menu bar of macOS or the task bar of Win10/11 - give some basic general information. the desired specifications were: - Not eating too

Introduced with the Nextion Editor v 1.60.0 in early 2020 as a container for startup code, the program.s file allowed for the very first time to execute code before the startup page (which was always page 0) was loaded. Although we have been using it many times in our demo projects, and since every project compiled using Nextion Editor v 1.60.0 or newer makes use of it, even when you do not touch at it, I think that it's time to have a deeper look to get most out of it.

This is the third and last part of this article series where we wanted to have a deeper look on how to develop a Nextion project systematically, efficiently, and at a professional level. After we talked about gaming mathematics and win plans in the first part, and about animation and timing in the second part where I showed you already a raw proof of concept, it's now time to add a nice GUI and the credits handling, and to adapt and to assemble all the code snippets elaborated during the previous articles, and then, we'll be done!