Hello Guest it is November 13, 2019, 12:39:20 AM

Author Topic: Actions verses Events  (Read 894 times)

0 Members and 1 Guest are viewing this topic.

Actions verses Events
« on: October 10, 2017, 02:18:54 AM »
Hi All,
have got myself confused again...looking at some buttons, Load G Code, for example. It has a Left Up Action of Gcode Load.

I have scanned thru the Lua script and found no Gcode Load function. The drop down list of Actions show a number of functions/actions for which
I can find no code. Am I correct in assuming that these functions/actions are coded in the core where I can't see/edit them?

All the events (left up, left down, clicked and lost focus) I can identify either the script or the function which is called within the Lua script. Presumably
I could dig around until I found the code and see/edit it.

While trying to de-mystify things I might as well ask what is the meaning and intent of Goto Page and Run MDI. Are there some examples I could view?

My wife left with my best friend...
     and I miss him!

Offline smurph

  • *
  •  1,143 1,143
  • "That there... that's an RV."
    • View Profile
Re: Actions verses Events
« Reply #1 on: November 03, 2017, 07:49:17 PM »
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. 

Re: Actions verses Events
« Reply #2 on: November 03, 2017, 09:18:47 PM »
Hi smurph,
thanks for that explanation, its gone a ways to demystify things.

I elected to change to Mach4 when I started trying to code in CE for Mach3 which seemed so buggy and confused. Lua, or rather Mach4s structure
with its multitude of API calls and so on has been a challenge. A little while ago I was helping a guy who was wishing to use 'ISIG_SPINDLE_AT_SPEED'
and he was flummoxed that the signal could exist without it having any function. I found myself defending the idea that an Object and its Action are
separate! Me the procedural Fortran whizz defending an object oriented approach! You've heard me claim I'm insane...you can add 'barking' to that

I know Mach3 has a whole swag of adherents but they are seriously missing out on the flexibility of Mach4.

My wife left with my best friend...
     and I miss him!