What is the name for a promoted WINMSG to solve the following. I have a promoted CREATE event which uses QUALIFY_EVENT to ensure all Editfields and Editboxes respond to a DblClick event. I wish to turn that into an OPTIONS call i.e. so the users can press either F2 or DblClick the mouse.

But it seems that I will have to put the code to call OPTIONS in the WINMSG of every single control that I have qualified. I'd sure like to have one piece of code that does this but cannot figure out the naming convention.

Is it possible?

Carrie,

Are you certain you want to use double-click for edit controls? Since this, by default, selects the text it seems a bit non-standard to simultaneously use it as your OPTIONS event trigger as well.

dbakke@srpcs.com

SRP Computer Solutions

I've never found a use for selecting text in this way but you may be correct (perhaps I'll use right or dblright click.

Do you have the naming conventions for WINMSG ?

We've posted an article on handling Promoted events in the SENL section of our web site.

The Sprezzatura Group

[/i]World leaders in all things RevSoft[/i]

Carrie,

AppName*WINMSG..OIWIN*

dbakke@srpcs.com

SRP Computer Solutions

Don

AppName*WINMSG..OIWIN*

That was the format I was trying, same as my other generic calls. I must be doing something wrong! Sure I've got Eventdesigner settings correct but I will look again.

Thank you for the confirmation and speedy response.

Carrie,

Sure I've got Eventdesigner settings correct but I will look again.

I hate to point out an obvious issue but have you recently changed the EventDesigner but have not yet exited OI?

Have you been able to capture Windows messages in a non-promoted WINMSG event?

dbakke@srpcs.com

SRP Computer Solutions

Thanks for your persistence! Yeah I've been in and out of OI several times. I have successfully captured 515 dblclick in a WINMSG in ny number of controls on the window but the promoted event does not get fired. I put the following

rv=Msg(@WINDOW , "Message is ":Message:@FM:T1)

in the WINMSG event of an editline control called EDT_NAME and it displays 515 correctly. I then copy that using

COPY_ROW "SYSREPOSEVENTEXES" , "FLD*WINMSG*MYTESTWIN.EDT_NAME" , "SYSREPOSEVENTEXES" , "FLD*WINMSG..OIWIN*" , "2"

but the WINMSG call is not displayed by any other controls. If I delete the WINMSG event from EDT_NAME that also fails to fire the generic code. Looking at System Monitor I cannot see any "Looking for.." WINMSG similar events in the way that you can with say GOTFOCUS or HELP even. I do have many other promoted events working.

Is there any chance you or anyone could confirm that a APP*WINMSG..OIWIN* is called.

Thank you again.

Carrie,

It sounds like your QUALIFY_EVENT message isn't being directed to the promoted WINMSG event.

Your CREATE event (promoted or otherwise) should have a line of code similar to this:

Send_Message(@Window:Control, "QUALIFY_EVENT", "WINMSG", 1:@FM:6:"*":@APPID:"*WINMSG..OIWIN*")

BTW, my System Monitor does show a "Calling AppId*WINMSG*..OIWIN* …" line during the execution of our application.

dbakke@srpcs.com

SRP Computer Solutions

Don

That solves it! Thank you.

Am I correct in thinking that the APP*WINMSG..OIWIN* is not detected in the same way then as APP*GOTFOCUS..OIWIN* or APP*HELP..OIWIN* both of which are picked up without the need to pass a qualified subroutine name to call.

I experimented and using your additonal QUALIFY_EVENT code (additional to the 515 dbl click qualify) so long as I pass NumParams:@FM:Progname then Progname can be anything in SYSREPOSEVENTEXES and it does not need to be to 'correct' naming convention. If you can clarify this?

At this stage even if I don't understand this part I am happy it works. Thank you for all your help, Saturday too!

Carrie

Carrie,

Am I correct in thinking that the APP*WINMSG..OIWIN* is not detected in the same way then as APP*GOTFOCUS..OIWIN* or APP*HELP..OIWIN* both of which are picked up without the need to pass a qualified subroutine name to call.

This is kind of correct. In the case of all "other" events, OpenInsight has been pre-designed to trigger them when it is appropriate. So if the specific event name exists in SYSREPOSEVENTEXES (and the event is enforced) promoted and control specific events will get compiled into the window and then called during execution.

The WINMSG was designed so we can design our own events against the many other Windows messages that can be detected but haven't been built into OpenInsight (e.g. Right clicks.) However, when a particular Window's message is captured this way it will automatically be directed to that control's WINMSG event and it will not, on its own, also have a promoted version of itself. The difference is that with OI events they are known at compile time, with Qualified events then are technically only known at runtime. Therefore it is necessary to redirect any control specific WINMSG event to the promoted WINMSG event if you want to manage all your WINMSG handling that way.

I experimented and using your additonal QUALIFY_EVENT code (additional to the 515 dbl click qualify) so long as I pass NumParams:@FM:Progname then Progname can be anything in SYSREPOSEVENTEXES and it does not need to be to 'correct' naming convention. If you can clarify this?

I am speculating a little bit here but my answer is "yes and no". Progname can be anything in SYSREPOSEVENTEXES, however, I believe you have to 1) structure the name as a valid event syntax name, and 2) use the EventDesigner to identify this as a new event.

We have considered creating an event for right clicks in this fashion. Instead, for a while now, we simply have our promoted WINMSG event call another stored procedure called Context_Menus to basically do everything we want.

dbakke@srpcs.com

SRP Computer Solutions

View this thread on the forum...