So since OI was basically rewritten was there ever a mapping of events and their processes done? If it was is it available?

Does OpenInsight 10 Presentation Server Reference Manual.pdf in the documents folder count?

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

Hi Dave,

I'm not sure what you mean by "mapping of events and their processes" - what information are you after exactly?

Regards

Carl Pates

Hi carl and andrew .. I am just trying to remind myself the events that fire and where in the process they fire. I will look for the pdf andrew mentioned.

I looked in the pdf andrew mentioned but it was a pretty short read :) after the words event chain there was a big blank space

Hi Dave,

I'm still not clear what you're after :)

"the events that fire " - Are you wanting a list of events that each control type can raise?

"where in the process they fire" - Which process? The individual chain for each event?

On the whole the majority of events have an execution sequence like this:

Event Script

System Event Script (or Promoted Event)

Quick Event

Some system Event Scripts will call into the Quick Event first and fire it in can the Quick Event handler tells them to stop. For example the system WINDOW CLOSE event handler will run a CLOSE QuickEvent first to see if's allowed to actually close. There are several others that do this, but I don't have a list of them to hand.

There is also the new "Has Priority" flag that you can set for a Quick Event - in this case it means that your QuickEvent is executed first rather than any system scripts - this is so you don't need to write Event Scripts for pre-event processing - you can put then in your commuter module just like your other code.

Regards

Carl Pates

Thanks Carl that is what I was looking for. I am trying to understand the other problem I have (the other topic) when a routine is being called but doesn't exist. Trying to figure out how I might have messed it up.

Do the events/processes change when it is in a mdi frame as compared to a regular window?

Hi Dave,

It's possible there's a problem with context.

Whatever QuickEvent is trying to use @WINDOW to call a Stored Proc as the commuter module is not expecting it to contain the name of the child (I assume that the MDI Child is NDW_SEARCH_SEL yes?)

So, how are you launching the child from the frame? Is it from a button, or from a menu item? Are you using quick events to do it?

Are there any quick events defined (like CREATE or GOTFOCUS) for the child or it's controls?

Feel free to email me screen shots of the quick events if you want.

You could also try using the event spy to see what events are being executed - that might help. To use it go the the System Monitor and type:

 SETDEBUGGER SPY 1 

And you should see the output in the EventSpy channel on the Output ToolPanel. If you want to see it in the System Monitor as per v9, then type:

 SETDEBUGGER SPY "" 1

You can also pass it and @fm delimited list of forms to track so you don't get _everything_. e.g. if you have an MDI frame called MDI_MAIN, and a child called NDW_SEARCH_SEL you can do this:

 SETDEBUGGER SPY [MDI_MAIN,NDW_SEARCH_SEL] 1

Basically the SPY method of SetDebugger has this API:

   retVal = SetDebugger( "SPY", param1, param2, param3 )



   // ----------------------------------------------------------------------------

   // [i]   param1   : Command to execute:

   //                :  '0' - Turn off the event spy

   //                :  '1' - Turn on the event spy - no IDE tracking  

   // [i]   param2   : @fm'd list if explicit window IDs to track.  If null then

   //                : all windows are tracked.

   // [i]   param3   : If TRUE$ then send all output to the System Monitor

   // ----------------------------------------------------------------------------

   // [r] Returns the current value of the event spy.

   // ----------------------------------------------------------------------------

Carl Pates

oh that is SWEET!

The Sprezzatura Group

The Sprezzatura Blog

World leaders in all things RevSoft

First thanks for continuing to hang in there …

I tried the setdebbuger spy but it just returned 0 in the monitor. Exact command was SETDEBUGGER SPY 1 then going into the window didn't show anything <sigh>

1) MDI frame which simply starts a child window called FRONT_WIN. It contains a buttons which creates child windows to MDI frame. The button's name is "NDW_SEARCH_SEL". It has a script like this

Declare Subroutine SSOft_Front_Win

SSoft_Front_Win(CtrlEntId)

RETURN 1

All buttons call the same code which is

Declare Function Get_Property

Declare Function Start_MdiChild

*	get frame name

ParentId = @window

Frame = Get_Property(ParentId, "MDIFRAME")

if len(Frame) then

	ParentId = Frame

end



*	build mdi information

MdiChildInstanceId  = Get_Property( 'SYSTEM', 'COUNTER' )

MdiDispMode = 0 ;* normal

MdiCreateParam = ""

MdiChildName = Field(CtrlEntId,".",2)

MdiChildTitle = ""



ChildName = Start_MDIChild(MdiChildName,"SIMPLESEARCH_MDI",MdiCreateParam, MdiChildInstanceId, MdiChildTitle, MdiDispMode)



Return

Child window, DBW_PLACEMENTS is a basic databound window. On ID control has a

quick Event which calls the DBW_PLACEMENTS_EVENTS module. For this control

specifically calls for the OPTIONS event.

options%20quick%20event.jpg?dl=0

IF i run this window (run from designer) it works correctly. All events on the controls work.

But if run from mdi frame the events are ignored.

caveats: There are 3 PE that are on all windows in the app.

CREATE which simply gets a record for the window and stores that in the

@WINDOW.@STATUSREC of the child window.

GETFOCUS which gets information from @STATUSREC depending on the control. It

also changes the background color to yellow

LOSTFOCUS which sets the background color to the original.

L

interesting … tried to put an image in the doc but it did not show. then

url is https://www.dropbox.com/s/mls9dbbfyl7z8rv/options%20quick%20event.jpg?dl=0

Spy shows events firing as you would expect when running the window plain. But when it is in the MDI frame no events are firing. I just get the error GPI002: Invalid Proc ID [DBW_PLACEMENTS] passed to the RTI_VERIFY_PROC procedure [FS100 - Record "DBW_PLACEMENTS" does not exist.]

Spy shows events firing as you would expect when running the window plain. But when it is in the MDI frame no events are firing. I just get the error GPI002: Invalid Proc ID [DBW_PLACEMENTS] passed to the RTI_VERIFY_PROC procedure [FS100 - Record "DBW_PLACEMENTS" does not exist.]

By the way spy is showing

DBW_PLACEMENTS*389_EVENTS (…)

SEND_EVENT (DBW_PLACEMENTS*389.EF_CLIENT_ID,OPTIONS, …)

but no event is happening because of the *error*

There has to be a reason that the forms in the MDI frame do not use the "_EVENTS" part of the name when calling the routines. Am I right in saying that you should be able to take a plain form and put it into a mdi frame and have it work?

I'm having a hard time reading this entire thread because the formatting of the text isn't working and much of the text is off the edge. So, I might not be addressing the exact issue but we did discover there is a bug with CLOSE events not getting called with MDI child windows. This is reported to be fixed in 10.0.8

Don Bakke

SRP Computer Solutions, Inc.

Thanks Don … yeah the CODE feature of the forum doesn't work worth squat <G> I am finding that most

events don't work correctly in an mdi frame. The fact that others have said anything tells me that it MUST

BE something that I am doing but can't figure out what it is … I simply have options qe calling the commuter

module .. and as soon as I put it into a mdi frame the event doesn't fire

THis is an OI problem … if I rename the Commuter module it will work. Why is this.

OI creates a commuter module with "_EVENTS" on the end. Then there is an option in QE to

use commuter module with _EVENTS … but this is not working. As i said I have to rename

the commuter module.

Dave

What was the quick event definition you used prior to v10? Was it the one that calls OBJ_CALL_EVENT? Or were you using the string @WINDOW_EVENTS directly?

Carl Pates

Hi carl … i believe some were but not these events. These events were all Scripts and I am moving

to a commuter module. So this is all new to 10. Pretty weird huh

Hi Dave,

I've found and fixed a bug if you're using the direct "@WINDOW_EVENTS" token ("Call Commuter Module (@Window_EVENTS) option) in the QuickEvent definition - basically it won't handle multi-instance window IDs. You'll see this fix in 10.0.8.

In the meantime - you can use the "Call Commuter Module (Legacy)" option which calls obj_Call_Event - this was used in v9 and contains code to handle "@WINDOW_EVENTS" with multi-instance windows

Or, you could set the CommuterModule property of your form to the name of your proc and use the "Call Commuter Module" option (the first in the list) instead. This way allows us to link the proc to the window so we can track the relationships for the RDK etc, as described here:

https://revdevx.com/2017/08/30/the-commutermodule-property/

Carl Pates

Thanks Carl … thought i was going crazy (don't say anything :) )

View this thread on the Works forum...