In GUI (Graphical User Interface) programming, the "ideal" is "State Programming". That is, programming with as little regard for the order of individual "events" as is possible. The theory being that events may, and often do, come in arbitrary, cached or cancelled, states - and should depend on each other as little as possible. This approach, as far as it can be taken, eliminates the vagaries associated with the arbitrary actions of a user with a "random access" input device - such as a mouse.

To give you an example, many GUIs produce exit events on one widget after producing the enter event on another. And while this may seem counter-intuitive, it provides the advantage of being able to know, in the exit event, the value and state of the "entered" widget. That way a decision may be made in the code based on the location of arrival, in the code run on exit.

In other systems, the exit event runs before the focus is moved into another widget, yet after it has left the "exiting" widget, providing a kind of "limbo" state - in which no widget has focus. Yet in others, the exit runs first, then the enter. In every case, the "state" programmer assumes nothing, but attempts to determine the state of the data and the program, as opposed to counting on one event being dependant on another event. That way, should different systems (GUIs) be used (as is the case in Sesame - which runs on both Windows and X11), or should one widget provide entirely different event sequences than another, or the underlying system change (as it did between 3.1 and 95), or should some events be generated by actions outside the application (such as clicking on MSWord while focus is on a widget in Sesame), the program is prepared to receive events in arbitrary order.

And, while attempting to determine event order in Sesame may well produce some efficiencies, if rigidly adhered to and assumed, it will create problems should that order change, whether due to a bug fix in Sesame, or FLTK, or Windows, or X11, or simply due to popular demand.

Quote:


If this is of any value, this is the sequence of events triggered during my preliminary test.

Global Event Triggered
On Form Entry Event Triggered
On Element Entry Event Triggered
On Immediate Element Event Triggered
On Element Exit Event Triggered
On Element Changed Event Triggered
On Form Change Event Triggered
On Form Exit Event Triggered

First I created Static Global variable in the Global code and assigned value to it

stat vGlobalEvent as String
vGlobalEvent = "Global Event Triggered"
Writeln (vGlobalEvent)

I have two LEs in in my EventTimer.db and each event has the same variable assigned the value stated above.

==========
On Form Entry Event

var vEventTrigger as String
vEventTrigger = "Element Entry Event Triggered"
WriteLn (vEventTrigger)

=============
On Element Exit Event

var vEventTrigger as String
vEventTrigger = "Element Exit Event Triggered"
WriteLn (vEventTrigger)

==============
Just like this assign the value to variable for each event and just sit back and watch the event firing after one another.

I heard Mark saying, he would like to have flexibility to change this event sequences if necessary and he would like us not get too hung up on this sequences.

I'll see what I can do to clarify the events.

Be very careful, especially using "WriteLn" in that bringing up the Writeln window and writing to it, can change the control flow in Sesame and alter your results. It would be more accurate to use the file I/O operations and then view your results after the experiment is complete.

Additionally, as in Q&A, the mouse combined with the GOTO statement produces the events of both. If you have a GOTO in an on exit for a LE, and the user leaves that LE to go to another using the mouse, the GOTO statement fires, forcing control flow (but not focus) to the subject of the GOTO statement. This is as it is in Q&A. If that LE also has a GOTO in its code, control flow and focus follow that GOTO - unlike Q&A, where flow follows the secondary GOTO (I think), but focus still follows the mouse.

If you are just experimenting, you can also use a GlobalValue or a global variable to accomplish the same thing. As you receieve events concat strings into the variable. Then when you are done use a single record mass update to write it to the Writeln window.