Following the instructions, I created two promoted events for GOTFOCUS and LOSTFOCUS. They work fine except for one thing: they don't fire unless I create a dummy event – either a script that returns 1 or a quickevent. I DID use the EventDesigner to set the Enforce flag to YES. I did save it. I did shut down OpenInsight and restart it. I did recompile the window, in fact I created new objects to make it recompile. It still doesn't work until I prod it with a dummy event call. What am I missing????

Wayne

Wayne,

What is the key structure you are using for the SYSREPOSEVENTEXES record?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

APPID*GOTFOCUS.RADIOBUTTON.OIWIN*

and

APPID*LOSTFOCUS.RADIOBUTTON.OIWIN*

G'day Wayne,

Send an e-mail to info@revelationsoftware.com.au and I'll email you back a tool that helps automate the creation of promoted event code.

Dave G

Wayne,

Sorry for the delay in my response. Your events should be working fine. I even created the exact events on my own system and they are firing without prodding. I assume you have a debug near the top of your code before any conditional statements. The reason I mention this is because GOTFOCUS/LOSTFOCUS events for Radio Button controls work slightly different than other controls. Even though the events are attached to the Radio Group control, it's the individual button controls that fire the events.

Therefore, if you have logic in your promoted event that is looking for the name of your Radio Group, such as the following…

Control=Field(CtrlEntId, "."[/color], [/color]2[/color], [/color]3[/color]) 
[/color] 
[/color]If [/color]Control EQ [/color]"RADIO_1" [/color]then [/color]debug[/color][/color][/size]         
               

…it won't work. You need to check for each individual radio button name or extract the radio group name from CtrlEntID.

When you enforced your events, did you do this specifically for the Radio Button control? You might want to examine your SYSREPOSWINEXES record and look at value 21 in the row where your Radio Group control is defined to see if the promoted event reference was compiled correctly:

CLICK*2*SYSPROG*CLICK..OIWIN* 
GOTFOCUS*2*SYSPROG*GOTFOCUS..OIWIN* 
HELP*2*SYSPROG*HELP..OIWIN* 
LOSTFOCUS*6*MYAPP*LOSTFOCUS.RADIOBUTTON.OIWIN* 
WINMSG*17*MYAPP*..OIWIN*[/color][/size]         
               

BTW, is there a reason you are creating promoted events specifically for Radio Button controls? Do you have promoted LOSTFOCUS/GOTFOCUS events for other control types? You might find it easier to create promoted events that are non-control specific.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I tried both a radiobutton-specific promoted event and a generic promoted event that checked to see if it was a radio button and acted accordingly. It's a moot point because I notice that field 21 of the radio button object in the compiled window is blank. The enforcement has not taken place. The EventDesigner window says they are enforced, but the compiler doesn't seem to care…

Wayne

Wayne,

It's a moot point because I notice that field 21 of the radio button object in the compiled window is blank.

I just want to make sure you were looking at the correct object in the compiled window. As I had mentioned previously, event handlers are not listed in the radio button control. They are listed in the radio group control. Did you check there?

dbakke@srpcs.com

SRP Computer Solutions, Inc.

No I didn't. Now I have. That only contains the CLICK event. Nothing more.

Wayne,

Hmmm…I can't think of anything else unless the form itself has somehow become corrupted. Based on your original post it appears that you have correctly done everything.

The reason it works when you add a Script event is because that now becomes the highest (i.e. least promoted) event in the chain. If you were to put your script event back and recompile your window you would see the following in the compiled window record:

GOTFOCUS*3*MYAPP*GOTFOCUS*MYWIN.RADIO_1 
LOSTFOCUS*4*MYAPP*LOSTFOCUS*MYWIN.RADIO_1[/color][/size]         
               

Once the chain has been entered into from the top, it will automatically call any events that follow in the same event handler chain. Your promoted events are control type specific and local to your application so they would be next in the chain. You mentioned previously that if you had a QuickEvent added then your promoted events would work as well. I'm a little skeptical of that because QuickEvents are at the very bottom of the chain and they wouldn't trigger OpenInsight to call any higher level promoted events.

Try creating a new window from scratch and see if you have any better success. If that doesn't work, you can try something else for fun. Put your Script event handlers back. Edit the compiled window and change the event handler names that I listed above to look like your promoted event handlers. For instance:

GOTFOCUS*3*MYAPP*GOTFOCUS.RADIOBUTTON.OIWIN* 
LOSTFOCUS*4*MYAPP*LOSTFOCUS.RADIOBUTTON.OIWIN*[/color][/size]         
               

By doing this you are now forcing the compiled window to think that your promoted GOTFOCUS and LOSTFOCUS event handlers are the top of the chain and that's where it will begin. Unfortunately, until you figure out why you can't get your promoted event handlers to compile into the window on their own, you'll probably have to repeat this step every time you recompile the window.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

I've been playing around with this a bit. First of all, I've discovered that while value 21 of the RadioGroup doesn't contain anything of interest, value 21 of the Window itself (field 1 of record 1 the EXE) contains a reference to GOTFOCUS*3*SYSPROG*GOTFOCUS..OIWIN*. So I copied my promoted event from MYAPP to SYSPROG and now I am getting an error of "too many parameters passed to SYSPROG*GOTFOCUS..OIWIN" when I run my test window and focus moves to the editfield. Figuring the number had something to do with the parameters being passed, I edited the window exe and changed it to GOTFOCUS*2*SYSPROG*GOTFOCUS..OIWIN* and the error went away, but it's still not actually executing the routine (the routine contains a Send_Info message and an instruction to set the backcolor of the calling object) judging by the results.

I'll continue to poke at this. Let me know if you think of anything else.

Thanks much for your help so far!

Wayne

One more thing:

I've noticed that the Editfields do have GOTFOCUS*3*SYSPROG*GOTFOCUS..OIWIN* in their value 21. Only the Radio Groups, Radio Buttons and Checkboxes lack a reference to GOTFOCUS*3*SYSPROG*GOTFOCUS..OIWIN*. Again, I have edit the EXE to change it to GOTFOCUS*2*SYSPROG*GOTFOCUS..OIWIN* to stop the error message.

Dang. In the event designer, I had set the GOTFOCUS and LOSTFOCUS events to Yes on the WINDOW, not on the RADIO BUTTONS or CHECK BOX! I didn't realize each object is selected separately. Learn something every day…

Thanks, Don.

Wayne

Wayne,

Did you not see one of my earlier questions:

When you enforced your events, did you do this specifically for the Radio Button control?

It was contained within one of my lengthier responses so you might have overlooked it. I was trying to be careful not to teach you how to suck eggs (as they like to say).

Well, as I like to say, I like a good mystery novel but I don't like any mysteries when it comes to programming. Glad it has been solved.

dbakke@srpcs.com

SRP Computer Solutions, Inc.

Ah, it's all in how the question is interpreted. I thought you were asking if I had created a GOTFOCUS.RADIOBUTTON.OIWIN event as opposed to a GOTFOCUS..OIWIN event! Hence my response that I had tried it both ways.

Oh, the lengths we go to to remain confused…

View this thread on the Works forum...