Yes, those are considered "stock actions" that the GUI provides that give users a quick way of accomplishing the most needed tasks.
The GUI has the concept of pages like Mach3 had. But they are mostly not needed with the advent of the tab control. Most of the screen sets now are built all on ONE screen page. But the screen can have multiple screen pages. But with pages, there are not any tabs to click to switch between them. So usually what is done is a button is placed on the screen that uses "Goto Page" to switch to a different page. "Goto Page" will take a page number (in the order that they appear in the tree manager) OR a page name.
"Run MDI" is for the MDI controls. MDI controls allow entry of MDI commands but there isn't anything on the MDI control to execute that code! So "Run MDI" takes the name of an existing MDI control as the parameter. When the button is pressed, the G code in that MDI control is executed. Most of the screens do the task of executing MDI code from the Cycle Start button and "Run MDI" is not used. There is switch code behind the Cycle Start button that determines whether or not to execute a file or the contents of the MDI control based on if the MDI control is focused or not.
I'll put some bonus info out here just because I know that this is commonly misunderstood and/or mysterious. Up and Down and clicked events, what is the difference? Well... MOST of the time users will want to use the left up event (action or script). This is because if the action or script is executed in the left down event, the GUI will appear locked for the duration of the event. The button will even appear "stuck down". Why? Because the event has to complete before the up event is fired. Using the up event can still lock the GUI for long running code but at least the button appears to come up instead of looking like it is stuck down. Most of the time, it is prudent to only perform fast running tasks in button scripts, even if you use the up event. The ONLY reason we have a down event is to handle momentary button control of things like velocity jogging. In the velocity jog case, the jog is started with the down event and ended with the up event. In each event's case, all the event is doing is setting a state, so the actual event code is very very fast. No long running code in buttons!!!
The clicked event happens when both a down and an up event occurs. And it ONLY happens when both the up and down events were fired. It is possible to prevent an up even from firing by clicking the button mouse down (down event happens) and while the mouse button is still down, moving off of the button and then releasing the mouse button (no up event is fired). No up event, thus no clicked event.
Steve
Guest
