Event Chaining and Promoted Events (OpenInsight Specific)
At 23 JUL 1998 02:06:17PM Don Bakke wrote:
I need someone to tell me if this is a bug or feature…
I have a promoted READ event, a window level READ event, and QuickEvent process for READ.
The idea is to have the promoted READ event perform some generic/common checks. If all is good then it returns 1 to allow the window level READ event to fire. Then if all is good in the window level READ event, it returns 1 to allow the QuickEvent process for READ to fire.
The problem seems to be that no matter what the promoted READ event returns the window level READ event always fires. The window level READ event works correctly, that is, a return 1 fires the QuickEvent and a return 0 doesn't.
Aren't promoted events supposed to work on the same principle? I've experimented with a CREATE promoted/window event chain and the same problem occurs.
Thanks,
At 23 JUL 1998 02:46PM Andrew P McAuley wrote:
Sorry Don but there is no bug… this is how event chaining works! To simplify
Do Most Specific EventDo Next Most Specific EventDo More Generic EventDo Generic EventDo Quick EventNow you could possibly Run_Event your promoted stuff from your window level stuff and then determine what else to do but normally it'll flow the way you're seeing it.
Sorry.
Sorry for delay on other topic as well, accidentally deleted my client proxy and spent 2 days reinstalling. Microsoft Incident Support suggestion "Reinstall Windows 95". D'Oh!
World Leaders in all things RevSoft
When do YOU want to REBOOT today?
At 23 JUL 1998 03:57PM Don Bakke wrote:
D'Oh is right! I completely went brain dead on the event order. Thanks heaps…this explains everything. However, it makes me wonder which order is generally more useful (i.e. specific to generic or generic to specific). What is your opinion?
At 23 JUL 1998 07:46PM Andrew P McAuley wrote:
Opinion? Hmm I tend to be retiring on my opinions normally
I view this as a standard OOPs model. The event handler for the control sub-classes the generic handler. To illustrate - I have a class CAR (4 wheels, steering wheel, engine, 2+ doors and gas tank) I sub-class to SPORTSCAR (which is CAR + GoFasterStripe). Now to see if SPORTSCAR it makes more sense to me to check GoFasterStripe BEFORE the other stuff.
I like the RevTi model!
FWIW
BTW Just to check - the d'oh was directed at me spending 2 days with MS Proxy Server - not you!
PS Although conceptually I'd prefer the Quickevent AFTER the event specific but I can see why this would be difficult….
World Leaders in all things RevSoft
At 24 JUL 1998 02:48AM Don Bakke wrote:
I can appreciate the current model. However, I think I know what is really bugging me. It seems like the system event handler occurs between the window level event and any promoted events. This is preventing me from creating a generic routine for validating READ's and then stopping them.
One area where this would be useful is when the key prompt has a sequential ID default. I have always disliked it when a form wants to read a record just because it gets minimized. I understand the logic of why this happens, but I still don't like it. So my READ events check to see if the VISIBLE property is set to 2 and if so they return a 0. Very simple. Now if this could be promoted then I won't have to worry about every new window that get's developed.
Does this make sense? Am I doing something wrong or do I understand the issue correctly this time?
Thanks…BTW, I knew the D'oh was for you. I was contributing my own self-D'Oh!
At 24 JUL 1998 03:25AM Andrew P McAuley wrote:
Surely this depends on where you promote them to? (Not that I've played with promoted reads, but normally there are several stages of promotion best witnessed by adding an event which just returns 1 and then watching the system monitor).
World Leaders in all things RevSoft
At 24 JUL 1998 10:07AM Gene Gleyzer wrote:
Don,
If you trace a Send_Event call in the System Monitor you will see something like: (window name is MYWIN, app name is MYAPP, comments …are mine)
Looking for:SYSPROG*READ*MYWIN. …
RUN_EVENT calling:SYSPROG*READ.WINDOW.OIWIN* …window specific READ
Looking for:SYSPROG*READ*MYWIN …
Looking for:MYAPP*READ.WINDOW.OIWIN* … !!app generic READ!!
Looking for:SYSPROG*READ.WINDOW.OIWIN* …
RUN_EVENT calling:SYSPROG*READ.WINDOW.OIWIN* …system generic READ
Looking for:MYAPP*READ..OIWIN* …
Looking for:SYSPROG*READ..OIWIN* …
Looking for:MYAPP*..OIWIN* …
Looking for:SYSPROG*..OIWIN* …
RUN_EVENT calling:SYSPROG*..OIWIN* … quick events handler
Looking for:MYAPP*READ.WINDOW* …
Looking for:SYSPROG*READ.WINDOW* …
Looking for:MYAPP*READ* …
Looking for:SYSPROG*READ* …
As you can see, the application specific generic READ event – MYAPP*READ.WINDOW.OIWIN* – is what you are looking for. It executes after the window specific READ, but before the system generic READ.
Gene
At 25 JUL 1998 02:01AM Don Bakke wrote:
Gene,
Thanks for doing the leg work for me. Based on Andrew's suggestion that not all promoted events occur after the system level events, I was just about to sniff this out and see which ones do and which ones don't.
Instead of using:
MYAPP*READ.WINDOW.OIWIN*I've been using:
MYAPP*READ..OIWIN*Unless one spends a lot of time studying the System Monitor (obviously not a bad thing!), you would never guess how many event levels and event names actually exist. Sprezzatura has the best article I've seen on explaining promoted events, but it would be nice to see a comprehensive list of all possible events without having to learn them trial and error.
Again, thanks to you and Andrew for getting me back on track.
At 25 JUL 1998 04:00PM Andrew P McAuley wrote:
Don
You don't know just how tempting comments like that are - then I go and over commit myself and end up disappointing…
It's in my wish list now though….
World Leaders in all things RevSoft