Event_Flow

Opto_Will

I have what I thought was a asimple question about Event_Flow = Event_Stop$ but now I am not sure about my question.

I was trying to hit the 'Emergency Stop' button in code so the entire Event chain stops in its tracks.

I was using :
Event_Flow = Event_Stop$ Return
to stop the process flow from continuing.

However, it would appear that upon retun to the Parent process, code continues. I understand that behavior for a simple Return but was under the assumption that adding the Event_Stop would stop continuation in the parent processes (not sure why I thought that TBH)

I understand well-crafted code from the get-go would be catering for this but there is a lot of legacy code that does not and that is what I am unfortunately looking at.

I know I can (and do) use something like "
If Error_Services('HasError') then Return
upon return to the Parent and then the same to the grandparent...
I could even use
If EventFlow EQ EVENT_STOP$ then Return (Like at the top of a Event module) or even work with the old Get_Status function.

But is there a magic command to do so at the grandbaby level without refactoring all that legacy code up the chain to the parent, grandparent, etc?

Also, while I am at it, when does the Event_Flow change kick in? I suspect only at the next event trigger so it, potentially, doesn't affect the current chain at all.
For example. What would it do here?
Event Parent Do some stuff Send_Event(CTRL, 'CalcSomething') ; // This Event forces an EVENT_STOP$ Do some more stuff Send_Event(CTRL, 'CheckSomething') Do Final stuff End Event

I (now) anticipate that I will still 'Do some more stuff' but that 'CheckSomething' will not run? Then 'Final stuff' does process?

DonBakke

Stopping the event flow (aka stopping the event chain) is limited to the links associated to the currently running event. By "links", I'm referring to:

• Script Event handler
  
• Promoted Event handlers (pre system)
  
• System Event handler
  
• Promoted Event handlers (post system)
  
• Quick Event handler
  

I think you were assuming, or hoping, that when one event triggers another event, that an EVENT_STOP$ in the secondary event would automatically stop the primary event. That is not how it works.

For example, when you lose focus on a key ID control, this automatically triggers the LOSTFOCUS event. Let's assume you have the following handler links in the LOSTFOCUS event chain:

• Script Event handler for the key ID editline control
  
• System Event handler
  
• Quick Event handler
  

These are your basic 3 handler links for an event. If your LOSTFOCUS Script Event handler returns EVENT_STOP$ (which is just a 0), then that will stop everything in its tracks. Full stop.

If your LOSTFOCUS Script Event handler returns EVENT_CONTINUE$ (which is just a 1), then it will call the System Event handler. The LOSTFOCUS System Event handler will compare the GOTFOCUS_VALUE property with the TEXT property of the control. If these values differ, then this will perform a Send_Event(@Window, 'READ'), thus suspending the LOSTFOCUS event chain and launching the READ event chain. Let's assume you have the following handler links in the READ event chain:

• Script Event handler for the Window editline control
  
• System Event handler
  
• Quick Event handler
  

If your READ Script Event handler returns EVENT_STOP$, then the rest of the READ event chain is aborted and control returns back to the LOSTFOCUS System Event handler. At this point, the LOSTFOCUS System Event doesn't know that the READ event chain didn't complete because it has no way of knowing at what point the event chain stopped. Thus, the LOSTFOCUS System Event handler would proceed as normal and eventually call the LOSTFOCUS Quick Event handler.

However, all is not lost. There is a proper way to handle this: Set_EventStatus and Get_EventStatus.

Thus, in your READ Script Event handler, if there is a situation where you want to stop the read (EVENT_STOP$) and you also want to stop the LOSTFOCUS chain, then use Set_EventStatus. When control returns to the primary event chain, then a check using Get_EventStatus will alert the system that there is an error and it should respond accordingly.

Now, I cannot promise that the system event handler will always do this, but I think most of them do.

Does this help?

Opto_Will

@DonBakke

In as much as it confirms I was wrong!!
I suspected your answer would be needing to have more robustly structured code.
I do that in many places in my code these days, just not using the Set/Get EventStatus functions.

Your explanation also explains why the few times I have set the Event_Flow to 0 previously it actually did what I intended (like to stop the "labeled common variable has been freed and is no longer valid" message when ending a Window)

Thanks Don.