As an OI newbie, I am learning how to use promoted events to reduce my coding effort. I am trying to trap the ACTIVATED event on MDI child windows, but I notice (through a system monitor trace) that only the event for the MDI frame is triggered, and the event is not fired when a child window loads! Are my observations correct, and can anyone suggest the proper method to trap the ACTIVATED event on MDI children?

Peter

Peter,

No, your observations are not entirely correct. The ACTIVATED event will fire for all windows: SDI, MDIFrame, MDIChildren, etc. Are you concerned that each window's specific ACTIVATED event won't fire or are you concerned that a promoted ACTIVATED event won't fire for those windows?

FYI, both will work but if you are having troubles then it will be for different reasons. That is, setting up and making a functional promoted ACTIVATED event is different than setting up and making a functional window specific ACTIVATED event.

I would need a little more information to give you more specific information that is helpful.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,

As a test, I created several promoted events and placed them in SYSREPOSEVENTEXES. The naming convention I used is

appid:"*":eventname:"..OIWIN*", and all the events fire as I expected, excepting ACTIVATED. For this event only, it fires just once - when the MDI frame is being activated after the MDI frame CREATE event. At least, this is what both the System Monitor and OENGINE traces report. While the MDI frame is active (as it always is), loading an MDI child does not fire the event, at least in my environment. I have coded around this by promoting the GOTFOCUS event, and testing if the active window has changed, but I would like to know whether my OI environment is misbehaving or if other developers have seen this problem.

Peter,

I have been using "promoted" events successfully for like 2 months. I am not sure I know the answer to your problem. I think this is the cause of your activated promoted event not firing…

My event designer for the "window" says the event "activated" is "not" enforced. So from what I have learned, only "enforced" events will fire "promoted" events.

You can change the "window" "activated" event to be "enforced". That most likely will start firing your "promoted" event.

To do this "execute" the "eventdesigner" and change the "window" "activated" to "YES" in the "enforce" column.

In Application Manager, in the list box, under "Openinsight", "Openinsight Executables", "Openinsight Form Executables", ONLY highlight "eventdesigner". Then under the "entity" menu, click "execute". That will start the window that will allow you to modify the activated event.

I am not an expert, so be careful not to change too many of the items there. Could cause a performance slow down.

Richard,

Thanks for the information. So much to know, so little time …

I have a related question, for Richard, Don, and others. It seems to me that while promoted events are very powerful, they fly under the radar screen because they are not well documented and are invisible to the repository views. I fear that six months after I finish the application, I will forget what events I have promoted, so I would like to step back a bit and reconsider how I am approaching this task. Rather than creating a large number of promoted events, I am considering creating ONE program to catch all events for a specific entity type, then using CASE statements to trap particular events. To trap all Window-related events, I would create a handler named "APPNAME*..OIWIN*" where APPNAME is the application name. Is this reasoning correct? Would such a program trap all window events instead of the handler SYSPROG*..OIWIN*? Or, can someone suggest a better approach?

Peter

Peter,

I think the "one program for all events" can not be done. I don't think there is a valid way to know what event called your "program". You might look into "RETSTACK()". Although I did and choose against one program for all.

I suggest this…

One program for each event. For like the "lostfocus" event, one promoted program. Then let that one promoted program call other programs.

See, I have 19 promoted events. Clear, Close, Create, Delete, Omnievent, Read, Size, Write, Gotfocus, Click, Hscroll, Colsize, Deleterow, Insertrow, Changed, Dropdown, Lostfocus, Menu. They then call the one program for each window.

Like the clear promoted event will use the @window variable to call the proper subroutine to execute for the clear event. And all the other events too.

Each promoted event is only 10 lines long. It calculates the subroutine name, verifies it exists, then calls it.

Now the called subroutine can be like hundreds of lines long. Because each subroutine is all the events for the window.

That way, so far, I only have one event that is not promoted. That is the CHAR event.

Now you must remember that since all 19 promoted events are calling the same one subroutine for each window, you must allow for that called subroutine to have enough arguments for the event that has the most arguments to pass.

Here is an example of my Clear promoted event.

WINDOW=@WINDOW

SUCCESS=TRUE$

EVENTSUB=GET_PROPERTY(WINDOW,'@EVENTSUB')

IF EVENTSUB NE NOTHING$ THEN

MESSAGE=NOTHING$

CALL @EVENTSUB(SUCCESS,MESSAGE,'CLEAR',CTRLENTID,CTRLCLASSID,BASVEKEY,BSUPPRESSWARNING,BMAINTAINFOCUS,CTRLIDFOCUS)

END

RETURN SUCCESS

The @EVENTSUB property is set in the Promoted Create event. That way if a window does not have an event for the promoted event, it will not try to call a non-existant subroutine.

I think this might be a good example for ya.

Remember that the @WINDOW variable might have an "instance" suffexed to it so you might want to drop the "instance" when calculating the subroutine name.

Richard,

Thank you. I will try out your suggestion.

Peter,

Sorry for my delay in responding. Been unusally tied up lately. Here are some additional thoughts:

1. Regarding your MDIChild windows not firing the promoted ACTIVATED event, here are a couple of possibilities: First, you might have created the promoted ACTIVATED event after you created your MDIChild windows and have not yet recompiled those windows. Your windows do not recognize the existance of promoted events until they have been recompiled. Second, you might have a scripted ACTIVATED event for each window and you are returning a 0 which is preventing the event chain to continue.

2. Regarding the "under the radar" concern with promoted events. Yes, this is a well known concern and has been for quite some time. Promoted events are still technically undocumented but highly recommended to use. Ira Krakow has been busy getting the new help files to include all of the well used but poorly documented features of OI. In fact, if I recall, Ira was going to use some of Sprezz's and my documentation when he gets to this subject.

3. Regarding the creation of a generic promoted event. Actually, I believe Sprezz has done this exact thing. I don't know if they are still using it. I seem to recall them having some difficulty with getting the CLICK event for buttons to be promoted. We however have always used the technique that Richard has described. Just create the promoted events as shells that call a master routine (we call ours Promoted_Events). Once the promoted event "shell" is in place you never have to play with it again. All work is done in the promoted event "commuter module".

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Don,Richard,

Thanks for all your help. The problem with the ACTIVATED event not firing was because the "enforce" flag in eventdesigner was set to "no". I switched the flag to "yes", and all is working now.

View this thread on the forum...