wait state issue


oldone
 

have 2 events, first is immediate (wait=yes I assume)

second runs after first is completed and that is wait no I assume

attaching each event to a button and processing the first then second, each works aok

together they fail and second appears to jump in before 1st has finished

my ignorance of conditional rules I assume


Steven Blank
 

You need to find out what the Wait properties are for sure – no guessing allowed. ;)

Synchronous (Wait = Yes). This mode raises the event immediately upon executing the Raise Event operation. The runtime engine suspends operations and proceeds directly to locate and execute the event's handler(s), if any.
IMPORTANT: Type: Internal Events (Zoom, Create Records, Record Flush, etc.) CANNOT be raised synchronously. If your program raises an Internal Event with Wait = Yes, NOTHING HAPPENS – the event simply vanishes into the ether. Internal Events can only be raised asynchronously (Wait = No).
Asynchronous (Wait = No). This mode places the event into the Event Queue, behind any unhandled events currently in the queue. In an online task, the event will not be handled until the task returns to the interactive mode, that is, awaiting user input. In batch tasks, when the event gets handled, indeed, even IF it ever gets handled, depends on the values of three batch task specific properties:
  1. Task Properties dialog, Behavior tab, Allow events = YES.
  2. Task Properties dialog, Behavior tab, Record event interval > 0.
  3. Options, Settings, Environment dialog, System tab, line 11, Batch event interval > 0.
If you're confused or unsure about any of this, I find the Activity Monitor to be an invaluable resource at runtime for sorting event handling issues.

HTH.

Steven G. Blank
SGBlank Consulting


On 6/12/2021 8:10 AM, oldone via groups.io wrote:
have 2 events, first is immediate (wait=yes I assume)

second runs after first is completed and that is wait no I assume

attaching each event to a button and processing the first then second, each works aok

together they fail and second appears to jump in before 1st has finished

my ignorance of conditional rules I assume


sherman levine
 

Magic could have avoided so much pain by labeling the choices Immediate and Queued

On 6/12/2021 1:48 PM, Steven Blank wrote:
You need to find out what the Wait properties are for sure – no guessing allowed. ;)

Synchronous (Wait = Yes). This mode raises the event immediately upon executing the Raise Event operation. The runtime engine suspends operations and proceeds directly to locate and execute the event's handler(s), if any.
IMPORTANT: Type: Internal Events (Zoom, Create Records, Record Flush, etc.) CANNOT be raised synchronously. If your program raises an Internal Event with Wait = Yes, NOTHING HAPPENS – the event simply vanishes into the ether. Internal Events can only be raised asynchronously (Wait = No).
Asynchronous (Wait = No). This mode places the event into the Event Queue, behind any unhandled events currently in the queue. In an online task, the event will not be handled until the task returns to the interactive mode, that is, awaiting user input. In batch tasks, when the event gets handled, indeed, even IF it ever gets handled, depends on the values of three batch task specific properties:
  1. Task Properties dialog, Behavior tab, Allow events = YES.
  2. Task Properties dialog, Behavior tab, Record event interval > 0.
  3. Options, Settings, Environment dialog, System tab, line 11, Batch event interval > 0.
If you're confused or unsure about any of this, I find the Activity Monitor to be an invaluable resource at runtime for sorting event handling issues.

HTH.

Steven G. Blank
SGBlank Consulting


On 6/12/2021 8:10 AM, oldone via groups.io wrote:
have 2 events, first is immediate (wait=yes I assume)

second runs after first is completed and that is wait no I assume

attaching each event to a button and processing the first then second, each works aok

together they fail and second appears to jump in before 1st has finished

my ignorance of conditional rules I assume



Steven Blank
 

Regarding the conditions for Enable and Propagate, I made this graphic flowchart for an event that was raised in a task layer two levels down from the Main Program to illustrate the hierarchy. Like any good event flowchart, begin at the bottom and "bubble-up".


oldone
 

Seems like it works but I cannot get the following:

Event A wait=Y

Event B wait=Y

Event C wait=N

The result is a mishmash ….I am lost......must be a code error that breaks the handler control list......

How to freeze the commencement of B



sherman levine
 

Why not queue B (set wait=N)?
Under some circumstances, I call B as the last step of A.


On 6/14/2021 9:05 AM, oldone via groups.io wrote:
Seems like it works but I cannot get the following:

Event A wait=Y

Event B wait=Y

Event C wait=N

The result is a mishmash ….I am lost......must be a code error that breaks the handler control list......

How to freeze the commencement of B




oldone
 

tried all permutations of yes/no wait on A B C

2 x 2 x 2 = 8 permutations

None work but Wait, Wait, no wait works better. 

What happens if within A if there is an event called that is wait no, will that affect the total package of the A event?

still getting older don


Steven Blank
 

Don,

First, remember that Internal Events (Zoom, Record Flush, etc.) cannot be raised with WAIT=YES – Internal Events can ONLY be raised with WAIT=NO. So, first, I'm assuming you're testing with events that are NOT Type:Internal.

Any event that is NOT Type:Internal and that is raised with Wait=Yes will cause the runtime engine to stop execution at that Raise Event operation and to proceed directly to the first-appropriate handler for the new event just raised.

If this new event gets raised within a handler that is being executed on some other event, then the runtime engine stops execution immediately with that Raise Event operation and proceeds directly to the first appropriate handler on the new event. When the new event has been fully handled, the runtime engine resumes execution within the handler where the new event was raised.

OTOH, if you raise an event with WAIT=NO within a handler on some other event, the new event gets placed into the event queue and will not be handled until after handling of the current event is fully completed.

You may not be seeing the behavior you expect, but I assure you, the behavior you're seeing is always entirely consistent with the rules. I've beat-up this whole event-driven architecture thing pretty extensively over the years and I've never found an exception to the rules, only my own incorrect assumptions.

Steven G. Blank
SGBlank Consulting


On 6/15/2021 6:15 AM, oldone via groups.io wrote:
tried all permutations of yes/no wait on A B C

2 x 2 x 2 = 8 permutations

None work but Wait, Wait, no wait works better. 

What happens if within A if there is an event called that is wait no, will that affect the total package of the A event?

still getting older don


oldone
 

And I am sure I have many incorrect assumptions....

I find them one at a time....

Your explanations are platinum class.....

don


oldone
 

An event that has within its definition one or more raise events therefore could have errors of consequence where
children events (I call them) may have their states incorrectly processed compared to when they were freestanding.

Am i correct in that, and if so this explains many of my programming errors, never corrected or identified by support
programmers. I fear that is the case where an event becomes a child and a wait no then is pushed to the end of the
parent, or at least out of place. I plead the 5th for ignorance.

ooch...is that correct....?

don


Steven Blank
 

Correct.

I have thusly shot myself in the foot as well many, many times.

Each time, close analysis of the Activity Monitor would reveal that events were not being handled in the order in which I expected, indeed, in some cases, if even at all. As a result of this self-bloodletting, I formed a habit of often creating a User-Defined event solely for the purpose of establishing and holding a place in the Event Queue – to guarantee proper progression of event handlers.

In other words, instead of raising Event B with Wait=Yes at the end of the handler on Event A, I might raise an Event C with Wait = No in that place, and then raise Event B with Wait = Yes in the handler for Event C. It's a subtle difference, but one that insures completion of an Internal:Type event before proceeding.

Steven G. Blank
SGBlank Consulting


oldone
 

Now that I must say is totally clever. You out fox the fox, roadrunner, and coyote all at the same time

A coyote story comes to mind.

.And another of my stories.....roadrunner cartoon and Acme gear.  How did it happen?

Long ago in depression, Alex R purchased a bankrupt Acme gear company. He needed advertising. A relative in the
entertainment industry put him together with a cartoonist and added the Acme gear name with the box idea.
Advertising.  And so the marriage was born. Cousin Alex R and great uncle Harry agent for Vaudeville talent and
WC Fields.


oldone
 

I believe you have provided the solution ….call you S. Holmes....

Indeed.

No combination otherwise worked.

Indeed.

don