Tweet
After struggling for many hours with creating the Menu Bar at runtime, Thanks to Desmond and rhosk, I think I finally have a handle on it.
The examples below show three ways to create and change the Menu Bar at runtime.
Note that in all three examples, the Menu Bar is Not Shown (disabled) in the AMS design view. you will have to preview to see the results.
In all of the examples, there are four desired actions.
1. To toggle the on-top function on/off.
2. To toggle the background music function play/pause.
3. To enable/disable the sub menus for the above functions.
4. To pass what state the above functions from page to page.
All of the examples accomplish the desired actions, with different methods.
In all the examples, the necessary code is in the Project Global-On Start, The Page Preload, On Show, On Menu, and the Buttons' On click events.
The Lua script resides in Scripts folder.
The first example uses Lua script to create and control the actions of the Menu Bar and is called by a run.script action in the Page Preload. The layout of the Menu Bar and the menu selected actions all reside in the script. The script residesThere are functions built in the Global section to control the selected actions, and to change the Menu Bar as needed.
The second example uses the Lua script to create the basic menu, but puts the menu changes and actions on the Page On Menu event. This streamlines the Lua script, but loads up the On Menu event.
The third example removes the Lua script altogether. The Menu Bar is created on the Page Preload event, and the menu actions are on the Page On Menu event.
In these examples, only one Lua script is needed for the whole project as the Basic Menu Bar will stay the same. This is good if all your pages will have the same basic Menu Bar features.
However, if you have a lot of different actions for each page, you may be served well by using Lua script for the Menu Bar.
An example of this would be if you put out a demo version of your application, then you just send a "key" to unlock the application after the trial. Then you would want use two different scipts for each page. A demo script and a regged script. Just use a trap technique to determine if it has been regged, then an "if" statement to run.script the alternate reg script.
It would be up to the developer which method would be easier to maintain, or change project to project.
The non lua script method will not have an external script debugging process. But, if it works in the script, it'll work in the Page Preload, too.
Lots of pros and cons, so it's up to you to decide waht's best for a given situation.
This post will self destruct in 10..9..8..7.
The examples below show three ways to create and change the Menu Bar at runtime.
Note that in all three examples, the Menu Bar is Not Shown (disabled) in the AMS design view. you will have to preview to see the results.
In all of the examples, there are four desired actions.
1. To toggle the on-top function on/off.
2. To toggle the background music function play/pause.
3. To enable/disable the sub menus for the above functions.
4. To pass what state the above functions from page to page.
All of the examples accomplish the desired actions, with different methods.
In all the examples, the necessary code is in the Project Global-On Start, The Page Preload, On Show, On Menu, and the Buttons' On click events.
The Lua script resides in Scripts folder.
The first example uses Lua script to create and control the actions of the Menu Bar and is called by a run.script action in the Page Preload. The layout of the Menu Bar and the menu selected actions all reside in the script. The script residesThere are functions built in the Global section to control the selected actions, and to change the Menu Bar as needed.
The second example uses the Lua script to create the basic menu, but puts the menu changes and actions on the Page On Menu event. This streamlines the Lua script, but loads up the On Menu event.
The third example removes the Lua script altogether. The Menu Bar is created on the Page Preload event, and the menu actions are on the Page On Menu event.
In these examples, only one Lua script is needed for the whole project as the Basic Menu Bar will stay the same. This is good if all your pages will have the same basic Menu Bar features.
However, if you have a lot of different actions for each page, you may be served well by using Lua script for the Menu Bar.
An example of this would be if you put out a demo version of your application, then you just send a "key" to unlock the application after the trial. Then you would want use two different scipts for each page. A demo script and a regged script. Just use a trap technique to determine if it has been regged, then an "if" statement to run.script the alternate reg script.
It would be up to the developer which method would be easier to maintain, or change project to project.
The non lua script method will not have an external script debugging process. But, if it works in the script, it'll work in the Page Preload, too.
Lots of pros and cons, so it's up to you to decide waht's best for a given situation.
This post will self destruct in 10..9..8..7.
Comment