• System usage: #define DYN_MENU 530
• Application usage: #define APP_DYN_MENU -1530
• Processed by: sxdwm display manager core (_exhibition-core)

Description: Some system module is requesting that the display system present a custom menu on its behalf. Unlike a normal MENU, which has its body loaded from a configuration file like m4_system, it is understood that this menu cannot be displayed by static/fixed-raster output drivers (such as the touch screen on a standard 8.x controller) and must be interpreted through dynamic drivers only (such as the tty dialog interface.) Static drivers will display a voice menu place holder with options to restate and cancel.

Parameter format: The parameters for DYN_MENU consist of the target session number, followed by a linebreak, followed by a full menu as represented in the m4_system file.

<session number>
menu <unique name>|<title shown to user>|<menu description>
- <unique button name>|<button label>|<command>|<return menu>
... (multiple buttons, one per line)
- cancel|<button label>||<return menu>

• If the menu title or button label is blank, the name will be displayed instead; use this to keep your total message short.
• If you do not know the session number that the user is currently accessible through, specify -1 on the first line.
  • This will only work if the user has already been using a menu.
  • You can or force a menu to be created by calling llMessageLinked(LINK_ROOT, 511, "", id), where id is the user's key. The session number will then be returned as the string parameter of a EX_SESSION_CREATED message.
• The <command> parameter takes the format: <message number> <string parameter> and executes llMessageLinked() statements from the perspective of the root prim. To perform a normal system @ command, use either the number 0 (feedback to local environment) or 1 (feedback only to active user).
• If the button simply goes to another menu, leave <command> blank.
• If the menu needs to be altered, omit the <return menu> value and call 530 again from within the command handler.
  • If the menu has the same name, the old one will be replaced.
  • If it has a different name, the old one will be forgotten. (See below.)
  • You should only use the <return menu> parameter to get back to static menus that have been constructed by loading them from a configuration file; these are never garbage-collected.
• Since the menu parameter must begin with a session number (see second bullet point, above), most commands that generate dynamic menus will need to know the correct session number when they are called. Within the button definition, the keyword $session can be used to capture this information.
  • Using $session (instead of hard-coding the session number this menu was constructed for) will make the menu more resilient if multiple users request it simultaneously.
  • For examples of this in use, see the standard m4_system file in the controller root.
  • If you do not use $session, a collision will occur if two users are using your menu at the same time.
  • $session cannot be used on the first line; if you absolutely don't know the user's session number, you should create a new session first, with llMessageLinked(LINK_ROOT, 511, "", id)
• If the button should require manager access or above to press, replace the - at the start of the line with a +.
• Pagination is not automatically handled.
• To maximize compatibility with static drivers (see 'Description' section, above), the menu must contain a button named 'cancel', regardless of its label.

-1
menu main
 - subsystems ||| subsystems
 - cortex ||| cortex
 - personas || 16 $session
 - follow || 1 follow
 - status || 0 power status | main
 - about || 1 about | main
 - applications || 27 $session
 - perform || 23 $session
 + manage ||| manage
 - devices || 240 $session
 - reboot || 0 shutdown -r now
 - shutdown || 0 shutdown -h now