This will have several parts to it which I will post below.
This is Part 1 with a general overview.
Part 2 will have code comparisons of the old vs. New code for menu's.
Part 3 will have "How To" examples to accomplish things.
I am not covering how to use the menu creation tool that Cerveza covered in the Sticky Menu post.
Menu: Part 1It has been a while since the menu code was updated. At first it seemed a little confusing to implement because I had always used the Menu Designer and the old version of EUO. I made very few modifications without that tool.
There is no tool to create the new menus and it has 2 affects:
1) The nice new features are not being used by new scripts
2) Old scripts and styles are often broken
There are not a lot of examples on how to write good menu code now. I have been offering to modify old menu code that isn't working in scripts for others and decided that a simple guide might help.
What happens to old menu code? Does it still work or simply break scripts?The old menu code can still work and most of it's features are still there. That is the good news. The bad part of this is that the rules are more strict now. If the original script didn't follow the current (revised) rules, then it is very easy for the menu to break. It will seem like a script will either not work or work intermittently and require stopping and restarting to get it to function again.
My goal is to make clear the rules that a programmer needs to follow and show some common ways to get around what used to be "the method" to have dynamic menus.
The old menu code would allow a single menu vs. the new menu code allows multiple menus.
This makes the new menu code more efficient and flexible than the old way.
There is 1 basic rule:Each element on the menus must have a unique name. (Re-using names will cause it to break.)
Functional Changes with new menu system:menu shape is really emulated via "menu image... "
Old menu creation commands vs. New menu creation commands
New menu commands create forms that are 10 pixels larger in both the X and Y axis than the original commands. This leaves additional space on the right edge and bottom edge of menu's. If you are really dependent on screen real estate - this may affect your overall screen layout. Offsets for where everything is placed is correct, just that the form is larger.
Restrictions:menu shape can't have dash lines or rounded corners
menu transparent only applies to old menu code
menu font transparent only applies to old menu code
A few commands no longer exist: menu image pixline (this could be accomplished with a sub to process the data to draw the line with pixel/line statements)
menu hideeuo
New additions:Panel
Radiobutton
pushdef
popdef
setdef
getdef
setprop
Every element has a parent (along with other new properties)
Logic changes:If a script used multiple menu's in the past, it was done with "effects". Maybe it would create a menu for setup, then clear it and recreate the menu for running the script.
It could have a button to go to the setup and what would be done:
-clear the running script menu
-rewrite all the setup elements
-get the information
-clear the setup menu
-rewrite the running script menu all fresh
Separate forms (menus) can be created now and simply use "setprop [formname] visible [#true|#false]" to hide one of the other to accomplish the former behavior. The good part is that the menus do not need to be recreated, but can simply be updated and change the visible setting.
The old system could change a Text element with 'menu set [text]', but all too often the script would delete the former element and create a new element in it's place with the same name. (This is the most common violation of the new rule to have unique element names, by the way, and usually makes the menu "break".)
If the old system needed to display some message, an ad hoc 'menu text' element was defined and then subsequently deleted. It would be recreated the next time the message
was displayed.
Similar code was in use often to make buttons, then change the button place function by deleting/creating a new button in it's place.
This method of
delete/create violates the unique element name requirement now.
How to revise the delete/create code?There are several functional examples in a post below, but here is the concept:
Create a subroutine to create all the menu elements that will be used in the script.
This is nice because all restructure changes in one place, too.
Now set the visibility #false on each of the elements you want to use later, but don't want displayed all the time:
menu button Mybutton 10 10 30 20 My Button
menu setprop Mybutton visible #false
Later in the routine where you want to bring forward the element, you can set the element
you want to turn off to invisible, while changing the "hidden" element to be visible:
menu setprop ActionButton visible #false
menu setprop Mybutton visible #true
... Do some stuff in your script ...
; restore the buttons:
menu setprop Mybutton visible #false
menu setprop Actionbutton visible #true
Former "#menures = Closed" value only works for form0.
All other forms when the "X" at the top right is clicked will set #menures = [formname]
Old code anamolies:menu clear
Deletes all forms except for form0 (the classic menu)!
sets #menubutton to nothing (used to be N/A)
running old scripts require setting #menubutton to N/A after menu clear statements to behave the same as previously.
Menu delete/Menu [create] looks like it worked, but clicking on a button is unresponsive use the visible #false/#true method to fix it
Color Rules and Changes:Named colors of Windows 'Theme' only works with old method of creating windows and the Pascal named colors do not work with new menu
Attached to this post is a subroutine that can be called to set colors to variable names.
-addresses many usable colors (including a direct correlation to the old color values).
-creates all the windows 'theme' values as variables with settings for a default windows theme. If you want to change your theme colors you can adjust the
settings in the ColorNameSub.txt routine.
Save the attached file in your Easyuo directory and call it during script setup to make the color variables available to your script.
Where the Easyuo commands could reference "red" or "black", now you would reference a variable named "%red" or "%black" respectively. Many colors are included in the subroutine.
Groupings by new property Parent:All elements have a parent. It could be a form or a panel.
The parent is inherited by the current default parent.
-The default parent is either the most recently created form or panel or established using "setdef parent [form or panel name]"
-Changed after element creation using "setprop [element] parent [form or panel name]"
All Radio buttons in the same parent - only 1 can be 'checked', others in the same parent are automatically turned off. So in order to use multiple groups of radio buttons, use panels to keep each group of radio buttons.
Menu font deprecated and defaults expanded to include other properties:menu setdef replaces all but "menu font transparent"
menu getdef allows seeing the settings
Pushdef/Popdef allows protected logic elsewhere so you can have your own settings.
menu pushdef
menu popdef
If you will create your own menu to go with a routine, you would structure it enveloped inside the pushdef/popdef commands.
Instead of using Display, you could create a menu form that displays the message. This would work in called libraries and the menu can live after the library call is done.
