As I finish my 3rd OI application in rapid succession, I find myself torn between my long-standing love of LH, and the ever-present feeling that a working OI app is a fragile flower, ready to self-destruct with the next code change – or maybe I'm the fragile flower and OI has nothing to do with it.

I've had a ball creating a neat set of tools to make development easier, but despite the hundred learning curve battles I've fought and won, there are still a few that persistently elude me. Here's one I need help on – event sequencing:

I know and accept that the programming world currently believes event-driven programming is the only valid model, but as long as the phenomenon of cause and effect persists, and time runs sequentially, it will still be important, at times, to know what comes before what comes after.

I've written some control update tools that indirectly trigger events. The question is what are the rules for determining the sequence in which events execute. It absolutely is not the sequence in which they are triggered, of course, but I hope nonetheless that it is deterministic, rather than dependent on the attitude and goal-directedness of each event.

For example, I have an event handler that simplifies as follows:

status=routine_that_triggers_event_1

status=routine_that_triggers_event_4

return 0

The Event 1 handler triggers Event 2 and the Event 2 handler triggers Event 3. My simplistic mind needs to believe that the events execute in the following order: 1 - 2 -3 - 4

Experience and non-procedurality shows this is not the case. Can anyone explain how to predict the event execution sequence?

Since this is a generic tool, I can't roll the various event actions into one program, because earlier events, at programming time, don't know what action later ones are going to take. The only thing I can say for sure is that each event needs to have earlier (that's MY view of earlier) events complete their actions first.

Are there rules for analyzing this stuff, or shall I just add the last few handfuls of my hair to the pile already heaped on my keyboard?

Thanks in advance.

"Baldy"

John,

As a veteran in this paradigm called "events" I can truly say that I share your pain. As far as the stability of OI is concerned we too have had our worries over the years but at this point it can be a pretty stable environment as long as you have mapped out the pitfalls in advance. Unfortunately, only experience or someone's development diary can give this to you.

Event oriented programming when properly understood makes for a far more flexible and powerful application. The concept, I believe, has been made more confusing and obscure than necessary. When we (or I) first began to learn OI it was very difficult to grasp because all the documentation kept implying that it was far different than the old DOS linear based processing model (i.e. Processes in AREV.)

The truth is, however, that there is a lot of similarity with AREV processes and OI events. This is especially true with OI because it cannot truly multi-task or run multiple threads. Once jRev is released then this may change the rules somewhat but I'll wait and see.

Your general question is difficult to answer in one general response. Yes, there is a sequential order to event processing (this is obvious) and yes there is predicitability to their order (which may not be obvious at times.) However, there are several issues that makes this even more interesting. For instance:

1. Each normal event can have a scripted (aka procedural) process, a default system process, and a QuickEvent process. Each of these have a default sequence but can be modified somewhat as well.

2. The above referenced sequence can cause confusion if the effects of the system level event are not understood correctly. For instance, someone might put some code that is called by the WRITE QuickEvent. In normal operation, the system level WRITE event has already written the record to disk and has cleared the form. Therefore, any attempt to retrieve the contents of the record (e.g. the RECORD property or @RECORD) will be unsuccessful since the record is no longer loaded. Therefore it is necessary to execute code from the Procedural WRITE event in order to get this information before the system clears it.

3. Some events automatically trigger other events. For instance, a DELETE event for a form will trigger the CLEAR event.

4. Some events don't trigger other events that we might assume would. For instance, a QBFNEXT event does not trigger a READ event.

5. Promoted events, if defined, can trigger before or after the system level event. It is all based on the naming convention given to the specific promoted event that determines which gets triggered in what order.

6. Finally, a misunderstanding of the Return 0/1 can create much confusion as it is possible to cause events to abort prematurely or to trigger an event twice in a row if not handled properly.

Therefore, it might be easier to deal with specifics for now. I believe working at this level will help the education process go much faster.

dbakke@srpcs.com

SRP Computer Solutions

Baldy,

1 2 3 4 has been a rule for quite some time now. With the occasional interjection of "buckle my shoe" this order has been relatively consistant. I say relatively because I asked all my family and got a 78.43% approval rating.

Events are triggered in the order they are fired. Like bullets, they only come out of the engine one at a time and they do not start processing until the game is over.

And event driven is not the only valid model. Valid models are Rebecca Rojimin and the one that does the desire commercials for Vickie's Secret.

I think your problem is you want to know what comes after. This is something we cannot know. Some say a great white light comes toward you and you feel a sort of inner peace. I find that hard to beleive. When I was gorged by a rampaging rhino after making a questionable comment about his parentage (turns out they really were married!) supposedly I had died for about 4 minutes. All I say was a dark red light with the faintest odour of brimstone and sulphur and something that sounded like moaning or screaming.

Oh, and you spelt ?!#&! wrong.

garygnu@compuserve.com

View this thread on the forum...