A few months ago Barry Stevens asked some good questions regarding the new Event Designer tool. Cameron responded with some good answers. I am, however, curious about one thing still:

What is the benefit of custom-defined events? I don't see where they would be any different than creating a SSP since, I assume, both must be explicitely called by my code. Or am I missing something here?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions

Don,

Yes, you can do all that with SSPs but there are 2 things that make it an invaluable tool:

1. Enforcing and event. Major if you want application-wide standardized behavior for a certain event

2. Ability to trap "hidden" events (VALIDERR comes to mind). You can now physically create an event of that name, and attach code to it. Whereas before you could have still attached your SSP in the right place in SYSREPOSEVENTEXES (App*event…), now you also get to see that event in design mode.

Dave,

Thank you for responding.

1. Enforcing and event. Major if you want application-wide standardized behavior for a certain event

This part I get, and am using with great results.

2. Ability to trap "hidden" events (VALIDERR comes to mind). You can now physically create an event of that name, and attach code to it. Whereas before you could have still attached your SSP in the right place in SYSREPOSEVENTEXES (App*event…), now you also get to see that event in design mode.

This is where I'm a little hazy. How do we know what "hidden" events are available? The documentation uses an example of creating an event called EXPLODE. I thought that was an arbitrary name, but based on your response I'm beginning to wonder if it refers to when Win95 windows are activated from the task bar.

I was under the impression that custom-defined events were more like OMNIEVENT's, just simply a place to hold event code but only executed when explicitely called (i.e. with a Send_Event statement.) But now it seems they are simply ways for the developer to trap system events that haven't already been defined by OI.

Am I getting closer?

Thanks,

dbakke@srpcs.com

SRP Computer Solutions

Actually Don, for #2 it's a little bit of both:

- You can find the names of the "hidden" events by looking at what gets called in System Monitor. For example on LOSTFOCUS, if there is a validation on the field, you will see calls to this mystery VALIDERR event. It's not specifically defined, but now you can add it in yourself, so that it is available at design time. Like that you can easily intercepr system error messages and replace them with your own or not display them at all.

- As for the EXPLODE example, I think that was just a simple example of a new event that ( like you thought) has to be triggered programatically. As for these events, it's your choice if you are going to choose to create a new event to channel functionality through it or use an SSP. An example of where a new event would come in handy would be the creation of a QBFREAD event. You can make all the other QBF events trigger QBFREAD by default (at the application level) throughout the system. Like that you can attach code IN ONE PLACE for what the screen should do when a new record is displayed in QBF mode (because the READ event is not triggered when a new record is displayed) .

Hope this gives you some more insight into Event Builder.

Don,

What is the benefit of custom-defined events? I don't see where they would be any different than creating a SSP since, I assume, both must be explicitely called by my code. Or am I missing something here?

If you want to have similar design (Form Des) and run (event chaining) functionality as the system synthetic events (e.g. READ) do, then create custom events.

If you promote your generic logic, as the SYSPROG READ event is, then you can also promote the logic that invokes it, as the SYSPROG LOSTFOCUS event does. For example, a promoted CREATE event that qualifies a WINMSG event which is implemented at a promoted level and translates the Windows™ message into one (or more) custom events. In this manner, you could create a CHAR event (although one already exists … but you get the idea though).

Cameron Purdy

Revelation Software

Hello Dave,

I need to do exactly what you suggested with a QBFREAD event. My question is, how do you go about making the other QBF events trigger QBFREAD by default?

View this thread on the forum...