Snippet - Lightweight Menu System - LMS

Lightweight Menu System - LMS

Lightweight Menu System (LMS)
1.0 Introduction
The Lightweight Menu System (LMS), Version 1.0, is a WPF based menuing solution. LMS allows the developer to create a custom set of menus, either hierarchical or interrelated, with no menu navigation logic on the part of the developer, while consuming a relatively small amount of overhead (lightweight).

Modules
• Spider
• T-35 Display
• Camera
If you dont have a camera, comment and/or delete the camera related code.

2.0 Touch Screen Menu Selections
LMS is based on six vertically aligned color coded touch screen buttons. A single menu consists of a title and up to six menu selections, one for each button. The sixth button is normally, but optionally, used by sub-menus to return to the main menu.

3.0 Main Menu
LMS begins with a single main menu that can consist of up to six menu selections. In turn, each main menu selection may consist of sub-menus that can be up to 3 levels deep.

1.0 Main Menu Title
2.0 Menu selection -> 2.1, 2.1.1, 2.1.1.1
3.0 Menu selection
4.0 Menu selection
5.0 Menu selection
6.0 Menu selection
7.0 Menu Example

4.0 Example
The LMS includes an example (see photos) that is a pseudo application to illustrate how LMS might be used for various purposes. On the Main Menu, 7.0 Example, is where the example begins. Of course one would normally take full advantage of the main menu. However, so as minimize disruption to the delivered menu layouts, this example is isolated to the last selection of the main menu.

Imagine an application that provides 24x7 home environmental information e.g. photo, temperature, air pressure, and light readings from any internet accessible browser. As such, it includes Wifi access to the internet, NTP server date- time synchronization, a web server for browser access, periodic home environmental snapshots, and data logging of the snapshot information to an SD Card. Obviously, there are a number of statuses, commands, and information needed to manage the application. This example provides a small example illustration of the value of a menuing system. The real-life version of this example has far more menu options.

5.0 Menu Customization
All menu customizations consist of menu layouts and predefined menu actions associated with each menu selection. The developer defines their menu customizations within a series of case statements in the method titled:

LMS_LightweightMenu ()

Each case statement generally consists of the following.
• Menu initialization.
• The assignment of button actions.
• The physical layout of the menu.

One can add, delete or modify case statements as needed. You may need nothing more than then main menu, or something as elaborate as the example. No need to carry any more case statements than needed.

Each of the above three elements making up a case statement are described in the following three subsections (5.1, 5.2, and 5.3).

5.1 Menu Initialization
Lets look at case statement 1000 (main menu). The main menu initialization consists of insuring there are no left over application message WPF text lines, and refreshing button colors. This is standard initialization for all case statements displaying a menu or invoking a application method.
5.2 Menu Selection Action
Every menu selection is associated with one of six color coded touch screen buttons. For each button a predefined action is assigned e.g., invoke another menu, disable a button selection NoOp, or invoke an application method. They are described in the following three subsections (5.2.1, 5.2.2, and 5.2.3).
5.2.1 Menu Action – Menu
Looking at case statement 7000, you will see six menu selections that are aligned with each of the colored buttons. In this example, all six selections define a menu (e.g., four digit case number) to be invoked. The Orange button has been assigned a value of lmsMainMenu (case statement 1000). In this instance LMS will return the user to the main menu when the orange button is touched. It is recommended you number your menus in a logical fashion to keep them well organized. For instance, 1.0 (1000), 1.1 (1100), 1.1.1 (1110), and 1.1.1.1 (1111).
5.2.2 Menu Action – NoOp
Often times you may not require six active buttons. Looking at case statement 7100 the green button (lmsGreenMenuAction) has its menu selection action disabled by setting it to lmsNoOp (case statement 99100). A NoOp action disables the button, has it turn dark gray, and invokes the LMS_NoOp method. LMS_NoOp does nothing. However, it is provided so that the developer may extend the logic of the LMS_NoOp method depending upon what the developer is trying to accomplish when a disabled button is touched.
5.2.3 Menu Action – Method
A menu selection eventually requires one to invoke an application method to acquire some data, format its output, and call on LMS_LightweightMenu() to display the output. Looking at case statement 7110 the menu layout is replaced with the name of the application method to be invoked. This method is provided by the developer. In this case it is StubShowData(). Note that the orange button is assigned action code lmsMainMenu. When the user finishes viewing the information they can touch the orange button to return to the main menu. All methods starting with the name Stub are for illustration only. They would be replaced with application developer provided methods.
5.3 Menu Layout
The menu layout describes the physical menu to be displayed on the T-35 display.
Case statement 7200 shows a menu layout that takes full advantage of all six selection buttons. It positions the menu title at line 0. The menu line items are set to line up with the colored buttons e.g., 2 (white), 5(yellow), 8 (red), 11(green), 11(green), 14(blue button), and 17 (orange). Note that the blue button is set to return the user to the prior menu as a convenient option.
Case statement 7220 is a very different situation where the menu items are lined up with the white, red, blue and orange buttons, while the yellow and green buttons are disabled (NoOp) and no menu line items are provided.
Note. A future LMS version will consider a feature to provide dynamic menu selections based upon the state of some condition (e.g., start/stop). A special application exit point would be provided to allow the developer to determine which menu selection items are available.

6.0 Special Purpose LMS Services
LMS provides a series of special purpose application services as follows.

1.0 Display Application Information
2.0 Take A Picture
3.0 Show A Picture (image) resulting from Take A Picture
4.0 Show Current Picture
5.0 Test Pattern
6.0 Screen Saver

All special purpose LMS Services begin with case statement 99xxx to avoid conflicting with the normal case statements 1000 through 7000.

The following subsections describe each of the above LMS services.

6.1 Display Application Information
An application may display up to 20 lines of text on the screen by invoking LMS_LightweightMenu (). Looking at case statement 7110 it invokes an application method named StubShowData(). Looking at the method titled StubShowData (near the end of the source). The method fills a 20 line message array called lmsMsgLine[]. Each item corresponds to one of 20 lines on the T-35 display. Each line can be up to 35 characters wide. It then sets the menu action (lmsMenuAction) to 99000. The action code 99000 tells LMS to display the contents on the T-35 display. The application invokes the following LMS method passing the parameters lmsMsgLine and lmsMenuAction.

MS_LightweightMenu(pictureImage, lmsMsgLine, lmsMenuAction);

6.2 Take a Picture
LMS supports a take a picture service and displays the resulting picture (image). The camera Take a Picture LMS service involves the following three LMS methods:

  1. LMS_TakePicture()
  2. LMS_CameraPictureCaptured()
  3. LMS_ShowPicture()

The above three methods are independent from the core LMS application so that the developer can use them as is or modify the code for camera related actions unique to their particular situation.

So how do we use this service? Lets look at the Take A Picture example starting with case statement 7100. The yellow button menu action (lmsWhiteMenuAction) has been set to lmsTakePicture (case statement 99400). When the menu selection, associated with the white button, is touched LMS case statement 99400 invokes the following methods:

LMS_TakePicture() . Looking at LMS_TakePicture(), one can see that it takes a picture and instructs LMS_LightweightMenu to display an instructional T-35 message. The example works as delivered, but the developer may extend this method as needed.

LMS_CameraPictureCaptured(). Taking a picture results in an interrupt that invokes this method that has LMS display the picture by passing the following two parameters to LMS_LightweightMenu() .

  1. lmsMenuAction (set to lmsShowPicture a.k.a., case statement 99500)
  2. pictureImage

LMS_LightweightMenu(). This method invokes case statement 99500 (lmsShowPicture) to display the picture. It invokes the method LMS_ShowPicture() and passes the picture as a parameter.

LMS_ShowPicture(). This method displays the picture as a Bitmap on a Border titled lmsImageBorder.

Note. Behind the scenes, LMS maintains two background Borders:
• lmsBgBorder. Used as a background border for Touch Buttons and Text.
• lmsImageBorder. Used as a background border for Pictures (images).

LMS manages the two borders transparent to the application developer. When the user touches the picture the ImageBorder_TouchDown() handler restores the lmsBgBorder and returns the user to the Main Menu.

6.3 LastPicture
Often an application is taking pictures on a periodic basis and one wants to show the last picture taken. This is supported in a particular way. Lets look at case statement 7100. The Red button selection action is set to lmsLastPicture( case 99600). When the Red button is touched LMS will invoke case statement 99600. This special case statement collapses the lmsBgBorder and restores the lmsImageBorder which results in the last picture being displayed. This may not work for your particular situation. If not, replace this process with one of your.

6.4 Display a Test Pattern.
LMS provides a built-in Test Pattern. It is useful when trying to see where lines of text line up relative to the buttons, etc. Looking at case statement 7500 the white button menu action (lmsWhiteMenuAction) is set to lmsTestPattern(e.g., case statement 99200). See provided photos of the test pattern.

6.5 Display a Screen Saver.
LMS provides a built-in Screen Saver. It is useful for an application that runs for an extend period of time. It allows one to darken the T-35 display when it is not in use. Simply touching the screen brings back the main menu. Looking at case statement 7500, the yellow buttons menu action (lmsYellowMenuAction) is set to lmsScreenSaver ( e.g., case statement 99300).

4 Likes

Well done and well documented. Thanks

Love the Bart Simpson ASCII art :slight_smile:

Great work Bob!

Thank you.