Hi All

I've got a nice commuter event that goes and works out the next point of focus on a form from the lost focus event with

focusID=GET_PROPERTY('SYSTEM', 'FOCUS')

I have another form that I am testing and no matter what I do, FocusID gets set to null at best ie like focusID='.

I have tried resetting the tab order, and debugging but I don't understand what the difference is between my test form and my nice application form, apart from the obvious - only the latter works.

Scott

Scott,

I don't think you can trust FOCUS with the Debugger running.

- Oystein -

Hi Oystein

You are so right. I replaced the debug with message boxes containing the details I wanted to look at like the value of the focusID, and that worked fine.

So what I would also like to know is does the FORWARD_EVENT bit work properly from a commuter proc. I noticed that the original code in the lostfocus that I am considering converting, skipping the forward event doesn't stop the focus from moving to the next control, but I am hoping that on a save, that stopping the forward event will stop the database update.

More testing I suppose.

Scott.

]]but I am hoping that on a save, that stopping the forward event will stop the database update.«

As long as your ssp is called in the write event script.

call myssp("WRITE",CtrlEntId)

return 0

Barry

Scott,

I was about to reply: If you really need to do a Forward_Event you must put that in a scripted event. So you must have a scripted event in addition to the commuter and quickevents.

But really I'm not sure. Hope somebody else can clear it up for you.

Btw - are you sure you need Forward_Event? Can't you organize your programming and events differently?

(Perhaps I've been lucky. Since I converted to the commuter way of thinking I haven't had much need for Forward_Event.)

- Oystein -

Hi all

Thanks for the info.

I guess I was trying to cut down how much stuff I have, it's quite nice not having a squillion little events attached to a form when I am trying to do an "update" for the client.

The reason for control of the forward event on the save is so that you can do something like

* validate stuff

* if valid then do the save (ie call forward event)

* else put up error message and skip the save

I am not sure how I could do that without the forward event bit, but I guess to keep things relatively simple I can call the commuter (ssp?) from the script code. Then at least I don't have to duplicate the validation routines from the lost focus stuff.

Scott

Janet,

I apologize for not paying very close attention to your situation. However, based on your last post I think you are attempting to use Forward_Event() in a non-typical fashion.

From what I gathered you want to control whether or not a record should be saved based on validation criteria in your commuter module, which was called by an event (Promoted or otherwise.) If so, then you should try to use the Return 1|0 at the end of your commuter module to control this. Perhaps you aren't structuring your commuter module calls to allow this. If not, then you should work on this.

Forward_Event() is meant to be used when you really need to execute event code "down the road" first and then have it come back and continue on with the current event. A simple example would be the need to have a READ event "go forward" and actually read the record. That way, the rest of the READ event can actually access the RECORD property of the window and have real data available. Otherwise, it would be empty.

[email protected]

SRP Computer Solutions, Inc.

Hi Donald

I think we discussed the returning of 1 or 0 from calls in the quickevents bit of the control events bit (the super commuter thread). Ie you can't do it. Mind you I didn't really experiment with it either.

I ended up leaving a heap of events that do return 0/1 in the original event script instead of putting it in the commuter event.

I still haven't figured out what a promoted event is or why you'd want to use it or how you would use it.

on a need to know basis…

Scott the mushroom.

To simplify things immensely, the calling order goes

Call custom event handler (CEH) for control/event combination if it exists

If CEH returns 1 or CEH does not exist call increasingly generic event handlers (promoted events) if they exist until one of them returns 0 or System level handler is reached

If 0 not returned previously Call system level handler

If 0 not returned previously Call Quickevent

so by the time you reach QuickEvent, 0/1 is irrelevant and all system level routines have taken place.

The Sprezzatura Group

World Leaders in all things RevSoft

Janet,

Do you have a grasp on how OI handles event chaining and in what order the regular events (i.e. script, system, and quick) get fired and when? Without this foundation, all sorts of confusion will come up.

Regarding promoted events, I thought I had responded before on what they are. "Need to know" is relative to how well you want to manage your applications. IMHO, there will never be an absolute need for promoted events because all functionality can be accomlished without them. However, once you understand what they do and how they work then I'll wager that you will want to use them for the shear convenience and efficiency it adds to your programming. If you don't learn about them then you'll never be able to make a decision use them in the first place.

[email protected]

SRP Computer Solutions, Inc.

Sprezz,

so by the time you reach QuickEvent, 0/1 is irrelevant and all system level routines have taken place.

Except for CLOSE, where system event handlers run last. (Any others?) But 0/1 is irrelevant for CLOSE too.

- Oystein -

Oystein

We'll bow to your superior experience of this but when we put a test form together that does a send_info on the custom handler before returning 1 then a send_info on the quickevent the system monitor shows this…

SEND_EVENT (AA,CLOSE, …)

RUN_EVENT calling:SYSPROG*CLOSE*AA. …

In custom close

Looking for:SYSPROG*CLOSE*AA …

Looking for:SYSPROG*CLOSE.WINDOW.OIWIN* …

RUN_EVENT calling:SYSPROG*CLOSE.WINDOW.OIWIN* …

Looking for:SYSPROG*CLOSE..OIWIN* …

Looking for:SYSPROG*..OIWIN* …

Forward_Event calling:SYSPROG*..OIWIN* …

REPOSITORY (EXECUTE,SYSPROG*STPROCEXE**SEND_INFO, …)

In close quickevent

which seems to suggest the quickevent last?

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezz,

…superior experience…

Not exactly. I just went and checked the online help - Guide to Application Development - Event Driven Programming - Understanding Standard Event Handlers and Processes - CLOSE:

- Oystein -

Having checked it looks as though the online help is wrong. The quickevent handler is called out of the generic oiwin handler for Sysprog.

Wonder why this one is docced differently?

The Sprezzatura Group

World Leaders in all things RevSoft

Sprezz,

I'll post it on the Works list. Mike collected errors in the docs. (I.e, WinWin said they'd update the docs, I said there were lots of errors and omissions, he responded with a question as to which they were, I replied back with some, but nobody else did. What a futile exercise for me - report on all the errors I already know about…)

- Oystein -

Oy-

I also follow this list- and every other on on the site….

Who's that lurking in the shadows…

Mike

Hi all

Don - I didn't mean I was a "need to know"=don't want to know". Mostly I do want to know. Usually when I have to teach myself something I go out and buy a couple of books on the subject and read them. The books available in this case were only the OI manuals. Which as Oystein pointed out, have their problems and I have no text by someone else to be able to get a different slant on things. I only have you guys.

So what I know is like a lace doyley - full of holes.

So I found the bit in the OI guide to app development. I found the bit with the event handler stuff. I only get more questions by reading it.

I take it that Custom Event Hander (CEH), which also gets called a Procedural Event Handler, is the bit that you write when you click on "scripts" in the Events bit under the Control Properties in Form designer. It shows up as CREATE on the drop down list (eg for the Create Event). This gets executed first.

Why is the default return for this RETURN 0 - ie execute no more stuff?

Why is it that even if you return 0 (for some events eg LostFocus) the process happily goes ahead and executes the system event handlers as well? No wonder I couldn't figure out what RETURN 1 or 0 was for. All I knew was if I got it wrong the whole lot broke.

System Event Handlers get executed next (after the custom event handler)

Although from the manual - the bit about Forward_Event subroutine - (in intro to event driven programming) - I can't figure out from the diagram, if you have a forward event in your CEH script, does the quick event ever get executed? Ie if you track the arrows from Forward Event, it never arrows control into the quick event but there are arrows out of the quick event back into the CEH!

Maybe things like this are why I have been avoiding the manual. I really need another one written by someone else to explain stuff like that.

Quick events - also known as "non-procedureal events" get run last if at all.

What I'd really find handy, but haven't found yet is a list of what events get run in what order eg when you open a form, that triggers activate, create, read (maybe), gotfocus etc - where is the documentation for this that shows what events get triggered and what order they get run in.

So I still don't know how you set up a promoted event.

It's not in the help topics/index and it isn't in the manual.

Stab in the dark

If you use the CEH script to call a standard subroutine (STDPROC) then you are using a promoted event? Actually if I remember it isn't quite like this but this is my best guess. Theoretically you'd have a bit of control over whether the system events and quick events get run for some events. (Ok I found out this was wrong)

If you use a Quick Event to call the STDPROC instead, then the stdproc is a commuter event?

Theoretically this is better because you can fix any mess that the system events made (apart from maybe a write) afterwards, ie on a LOSTFOCUS event, you can put the focus back where it belongs when it got lost because of the system event getting executed anyway. You have to use forward event and set focus to achieve this in the CEH script.

For the record, from the book, the "variations" are for READ, WRITE (dammit), CLEAR, LOSTFOCUS and POSCHANGED, CLOSE. I'm sure we use send_event stuff to stop writes when the data isn't valid, but I guess a commuter event is going to be too late.

On promoted events a direct question "what is a promoted event" got this from Don.

href=http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/B52B62480BE524CF8525674F000A2E7C?OpenDocument]http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/B52B62480BE524CF8525674F000A2E7C?OpenDocument[/url]

Not a clue from this how to actually create one, and I don't want to have the same process run for every single event either. I need to be able to customise validation etc.

Presently in this thread the chief Sprezz comes back with

www.sprezzatura.com/v1i7.htm And clicking on that eventually brought me up the senl which I have now read. DAMN Tricky stuff. The worst part is trying to keep track of the things, ie how do you know if your form is executing a promoted event or not, you'd have to write and run a report every time. Still unanswered questions: If you define an event for a given control in the normal way ie a gotfocus CEH script, will any of the promoted events execute at all after that? It looks like it doesn't but if it did can you control which ones? Personally I would prefer it to check backwards ie app-]form-]control so I could say for all lost focus events check that the cancel/close button hasn't been clicked before executing the lost focus control data validation code. I also have several buttons eg prev page, next page, first page, last page (for dealing with that pesky 32K/64K data limit problem) that run nearly the same code but this promoted event thing doesn't provide such a neat way of dealing with it as the commuter event stuff. And worst of all I have some code that looks similar across different events and the promoted event thing doesn't really deal with that either. I suppose if I tried to turn my thinking about this upside down, I could have one promoted event for the whole form (except it goes by event right?). I'd like one event for the whole form which has locate/on-gosub routines or a whopping big case statement or a mix, that has all the event code in it. Except how would something like this (as a promoted event/script) know which event was being executed? Well I guess it would because it would be the generic for one event but that isn't so useful to me. It might be damn handy on the update events (save/write) though, but only if it executed as well as any specific code. Gawd, the mess I would have if I had to recompile and re-release all my windows/forms (hair rending nightmares). Also if you copy the exe of one event to the promoted event id, how, when you are into the debug nightmare, do you find out months later, what the source code is/was? How do you recompile after you fix it? Is that why Andrew suggested having them all on one form, but what if you have layers ie some app-wide promoted events and some more specific stuff? Scott (less hair) </QUOTE> ---- === At 20 MAR 2001 01:55AM J Scott wrote: === <QUOTE>Hi all I hate it when I get the HTML half right Try again. [url=http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/B52B62480BE524CF8525674F000A2E7C?OpenDocument]Don's answer to what is a promoted event?

If we have to cut and paste.

http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/B52B62480BE524CF8525674F000A2E7C?OpenDocument

Scott

Now look what I made me do.

One last time (especially since my dodgy link seems to work in IE anyway)

href=http://www.revelation.com/8525652b0066bfaf/d739a1010f28f6798525656b00612ab1/B52B62480BE524CF8525674F000A2E7C?OpenDocument] Don's answer promoted event thread

Scott

Janet,

Mostly I do want to know…So what I know is like a lace doyley - full of holes.

I hear you. Many of us here trying hard to fill those holes so you can be encouraged and productive.

I take it that Custom Event Hander (CEH), which also gets called a Procedural Event Handler, is the bit that you write when you click on "scripts" in the Events bit under the Control Properties in Form designer. It shows up as CREATE on the drop down list (eg for the Create Event). This gets executed first.

Correct.

Why is the default return for this RETURN 0 - ie execute no more stuff?

It's just the way Revelation designed it. This has tripped up so many people who didn't know to change it to a 1 where it really matters (e.g. READ and WRITE events.) In some events it doesn't necessarily matter whether you return a 1 or 0 (e.g. CREATE event.)

Why is it that even if you return 0 (for some events eg LostFocus) the process happily goes ahead and executes the system event handlers as well? No wonder I couldn't figure out what RETURN 1 or 0 was for. All I knew was if I got it wrong the whole lot broke.

As I just mentioned, for some events a return 0 doesn't affect anything. That is, the system event handlers don't do anything. Also, realize that some events are "reactive" and not "proactive." What I mean by "reactive" is that the Windows OS has already done it's thing (e.g. place the focus of the cursor in a field) and now OI is simply responding (reacting) to this event - i.e. GOTFOCUS. The system event handler doesn't do anything else and, consequently, can't prevent the GOTFOCUS in the first place. A proactive event is where the system event handler, not the Windows OS, does the work. For instance, the WRITE event is something that is requested through OI, passed through the procedural event first (aka CEH) and then the system event handler does its thing and then finally on to the QuickEvent handler.

System Event Handlers get executed next (after the custom event handler)

Correct.

Although from the manual - the bit about Forward_Event subroutine - (in intro to event driven programming) - I can't figure out from the diagram, if you have a forward event in your CEH script, does the quick event ever get executed? Ie if you track the arrows from Forward Event, it never arrows control into the quick event but there are arrows out of the quick event back into the CEH!

Yes, the system event handler and then the QuickEvent handler both get called before Forward_Event() returns to your CEH script. This assumes that there were no problems in the system event handler that aborted the event chain (i.e. return 0).

Maybe things like this are why I have been avoiding the manual. I really need another one written by someone else to explain stuff like that.

Understood.

Quick events - also known as "non-procedureal events" get run last if at all.

Correct.

What I'd really find handy, but haven't found yet is a list of what events get run in what order eg when you open a form, that triggers activate, create, read (maybe), gotfocus etc - where is the documentation for this that shows what events get triggered and what order they get run in.

Others have made similar requests. Most of us have justed learned through trial and error (mostly error.)

So I still don't know how you set up a promoted event.

This is not docced officially but there is good documentation out there. Specifically, my favorite primer on the subject is Sprezz's article on the subject. I see (by reading more of your post) that you have already discovered this article. Therefore I'm posting the link here for other's benefit.

If you use the CEH script to call a standard subroutine (STDPROC) then you are using a promoted event?

No. The above article explains how to create a promoted event.

If you use a Quick Event to call the STDPROC instead, then the stdproc is a commuter event?

Whenever you use a common procedure to hold all your event/window code then this is a commuter module. You can do this via the QuickEvent/Stored Procedure method (our preferred), QuickEvent/OMNIEVENT method, or CEH/Stored Procedure method. There may be other methods as well. Also, not to confuse you, our promoted events are handled in a commuter module method. For now, however, just figure out how to promoted events and worry about making them very efficient later.

And clicking on that eventually brought me up the senl which I have now read. DAMN Tricky stuff. The worst part is trying to keep track of the things, ie how do you know if your form is executing a promoted event or not, you'd have to write and run a report every time.

It's not has tricky as you think. It can become messy if you attempt to work with every possible combination of promoted events possible. However, that is not practical nor beneficial. For instance, we don't ever create entity type specific promoted events (i.e., events keyed to an EDITFIELD but not an EDITTABLE.) They are always application specific. If we want to be more selective in execution then we'll just write code in the event to do make these decicisions. My suggestion is to create one event successfully, make sure you are comfortable with it, and then branch out to new ones.

If you define an event for a given control in the normal way ie a gotfocus CEH script, will any of the promoted events execute at all after that? It looks like it doesn't but if it did can you control which ones?

Actually, depending on the way you *name* your promoted event it can execute before or after your CEH. Typically, however, the promoted event will execute after your CEH because the most specific events (i.e. CEH) are executed first and then comes the least specific (i.e. promoted, aka generic, events.) Of course, all this assumes that your CEH or system event handlers successfully return 1. If you really wanted to control (i.e. turn on and off) your promoted events this want then just return a 1 or 0 accordingly.

However, having said all that, you will generally want to avoid using CEH's and promoted events IMHO. We manage 99% of all our events through promoted events and QuickEvent/Stored Procedures. The rare occasion we use a CEH is when we are writing a generic utility in SYSPROG (i.e. this utility is meant to be shared with other developers).

I suppose if I tried to turn my thinking about this upside down, I could have one promoted event for the whole form (except it goes by event right?). I'd like one event for the whole form which has locate/on-gosub routines or a whopping big case statement or a mix, that has all the event code in it. Except how would something like this (as a promoted event/script) know which event was being executed? Well I guess it would because it would be the generic for one event but that isn't so useful to me. It might be damn handy on the update events (save/write) though, but only if it executed as well as any specific code. Gawd, the mess I would have if I had to recompile and re-release all my windows/forms (hair rending nightmares).

Ahh…now you are getting the idea. This is what I was referring to above by putting our promoted events into a commuter module context. We simply create promoted event "shells" which only make a call to a common stored procedure. These shells pass a parameter identifying which promoted event they are so our commuter module can gosub/call the appropriate section of code. The beauty, of course, is that all changes are done in the stored procedure and the true promoted events never have to be touched again.

If I recall, Sprezz does something similar. However, instead of working with a lot of application specific promoted events, they have one major promoted event and track everything through this one funnel. I recall that there were some problems with this approach. Something like the OPTIONS event not able to be promoted or something like that.

Also if you copy the exe of one event to the promoted event id, how, when you are into the debug nightmare, do you find out months later, what the source code is/was? How do you recompile after you fix it? Is that why Andrew suggested having them all on one form, but what if you have layers ie some app-wide promoted events and some more specific stuff?

This is why you put minimal code in the actual promoted event and put all the truly functional code in a stored procedure. Then it is just as easy to debug and fix as with any other subroutine or function.

Scott (less hair)

Do they have Rogaine down under?

[email protected]

SRP Computer Solutions, Inc.

Hi Don

That was good. Especially the bit where the promoted event calls the stdproc. That must be one hell of a stdproc, because presumably it calls other stdprocs depending on what is required. Otherwise I'd blow the size limit (again).

Rogaine? Some sort of hair tonic in the context? Actually I do have lots of hair and it grows quickly, so as fast as I tear it out, there is more.

The only rogain/rogaining I know about and I'm not sure of the spelling has something to do with competitive running-orienteering where several teams of crazy people try to complete an orienteering course in the shortest possible time. The courses often take 24 hours to complete ie 100km or more over rough ground, and the competitors do things like running on forest tracks all night. It makes rugby union look like a game for softies. If I ever get involved in that sport - I'll be the one handing out bandaids and strapping icepacks to ankles and knees.

Scott.

Janet,

That must be one hell of a stdproc, because presumably it calls other stdprocs depending on what is required. Otherwise I'd blow the size limit (again).

Spot on. We generally start with one main stored procedure that has GoSub sections for each main event: CREATE, READ, WRITE, GOTFOCUS, etc. We name this main stored procedure Promoted_Events() for obvious reasons.

When this routine gets too large we then break out a specific event into it's own routine, for instance: Promoted_Create_Events().

The real tip for success is making sure everything is a function and that each function returns back to the calling function an appropriate 1 or 0 so the true promoted event will chain correctly.

Rogaine? Some sort of hair tonic in the context?

Yep. A well known hair regrowth product in the U.S.

[email protected]

SRP Computer Solutions, Inc.

Scott,

I don't think Don properly cleared up the confusion with RETURN 0. When you select an event and press the Scripts button the Event Editor appears - showing you the user (scripted, custom, whatever) code for that event. But even if there is no event there yet, the Event Editor shows you a RETURN 0 line. But don't be fooled. Until you really start keying in something and compile it there is no user event handler and no real RETURN 0 that will break the chain! The RETURN 0 you see is just an embryonic script for you to develop.

Major design flaw if you ask me.

- Oystein -

Oystein,

I don't think Don properly cleared up the confusion with RETURN 0

After all of my typing this is ALL you can say? Sheesh…

[email protected]

SRP Computer Solutions, Inc.

Don,

Apologies. I was really impressed by all your typing. Both the content and the sheer volume. And Scott's too. But while reading (and reading and reading) I fell into a trance-like state where this vision of Revelation's server bursting at the seams appeared before my inner eye. So - coming back to my senses - I tried to be brief.

- Oystein -

Hi Oystein

Don didn't confuse me with that return 0 thing. Somewhere I read that the return 0 isn't really there until you type in some script (beware the phantom script).

What bothered me was that if you do type in some script it is still return 0, which I thought was best ie what was supposed to make things work best. In fact it stops some things from working at all.

The unscripted script is return 1 (ie if you don't type anything) except when you look at it, like the electrons in heisenburgs uncertainty principle, it shows as return 0. But if you script something, and you wanted it to work the same way as it used to but with maybe a bit of extra fiddling like a conversion or look up or something, then you get return 0 as default and what used to run, no longer does. I can't believe I haven't had more problems with this.

The only way to say everything in a short post would be to write poetry. And then I wouldn't understand it.

Scott.

Scott,

What would be nice was if the whole chain was exposed. So we could see each handler, both our own and the system ones. So we could see the links between them, and also change the order.

Btw - has quantum computing reached Australia already?

- Oystein -

View this thread on the forum...