I understand the flow of event handling goes like this…

1) User code (scripts).

2) System event handler.

3) Quick event.

I just gotta know… Why is the "Quick event" after the "System event handler"? Why isn't it before the "System event handler" like the "User code"?

Is there any way to cause the "Quick event" to occur before the "System event handler"? One example event would be the "clear" event for the window.

Because quickevents are implemented BY the system layer code and changing it now would doubtless break things

The Sprezzatura Group

World Leaders in all things RevSoft

uh…. ummmmm… ok then. :o)

I wanted to create one stored proceedure to process all the events for the whole window. Is there a way to do that? Whould it have something to do with "promoted" events? Because without being able to catch the event before the "system event handler", I am wasting my time.

Do "promoted" events fire before the "system event handler"? Kinda like the "user code" does?

Correct - user code -] increasingly generic promoted events -] system events -] quick events. http://www.sprezzatura.com/senl/volume1/v1i7.htm#_Toc447357930

The Sprezzatura Group

World Leaders in all things RevSoft

Richard,

I wanted to create one stored proceedure to process all the events for the whole window. Is there a way to do that?

Perhaps even a simple way? Depends on what you mean when you say you want one single SP (a commuter function) do all the form's events. Do you want all your programming in one SP to avoid having code all over the place? Or do you need to get totally rid of the scripted event? If it's just the former I suggest you put the CLEAR programming in the commuter function and have a scripted event with a single line that calls your commuter with the appropriate parameters. Use the same parameters you would use for a quickevent.

- Oystein -

Richard,

If you haven't implemented Promoted Events before then study the Sprezz article well. Also, at our next SoCalRUG meeting (hopefully to be scheduled soon!) I can give you our documentation (which includes the Sprezz article) for our Promoted Events presentation at the Las Vegas conference.

Essentially Promoted Events can be designed so they fire before or [/i]after[/i] the system level event. It's all in the naming convention used for the Promoted Event in question. This is cool for AREV programmers who are used to Pre- and Post- processes.

We use commuter modules for virtually everything (including Promoted Events themselves). Most of the time we can get away with using QuickEvents to launch them. However, as you figured out, some events need to be processed before the system level (i.e. CLEAR, WRITE, CLOSE, READ, etc.). In these cases we have the Promoted Event call our commuter module for us.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Donald,

Your documentation would be great! If you are willing to share it. You should have my email address from the user meetings.

Thanks Sprezzatura, that saves me testing time and releaves my concerns.

Richard,

I have your email address but the documentation is designed in QuartExpress on a Mac. That is to say, it isn't something I can email you as is because we had it professionally printed for our presentation. This is why I said I would give you copies at the next meeting.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Oystein,

Definately wanting all code in one place.

I have done a few promoted events. Messed with them a little. I am really trying to move all code to one location, if that is possible.

After considering a "hard copy" of my code, I realized it would probably take up hundreds of pages. Then I thought about one stored proceedure for each window, rather than anywhere from 20 to 60 mini scripts for each event within the window.

So that is what sparked my thurst for knowledge for the promoted events.

My "CLOSE", "GOTFOCUS" events are basically all identical. And then there are the "CLEAR", "READ", "WRITE", "LOSTFOCUS" events, They are almost always unique.

I really like the idea about having all the code in one stored proceedure, and having promoted events calling this one stored proceedure.

I am going to spend a couple days checking it out and testing it to see if it is workable for me.

oh… oops… DOH!!!

I think I understand now. hehehe

"I have so much time and so little to do."

"Strike that! Reverse it!"

Willie Wonka and the Chocolate Factory.

View this thread on the forum...