Are the Promoted Events in Frameworks compatible with new RTI stuff?

JimPeters

I just finished upgrading a copy of our application from 9.2.0 through to 9.4 for testing. The application seems to run fine and all the OLE controls and SRP Frameworks promoted events seem to work in the application.

But, in the IDE I noticed that in the RTI_CFG_INET window that is used to set access to the INET routines, the button clicks are not working. In a clean new install of 9.4 they work as expected, so I suspect there is some incompatibility with event code RTI is using for form events now. I think this is a recently created form that probably has more modern code.

Before I get too deep in this, does anyone here have some knowledge of this issue? I would like to figure out what is going on and find a fix before upgrading the production system and finding some bigger related problem.

I did put a debug trap in the Frameworks PROMOTED_EVENTS routine to see if I could catch the CLICK event and see what was eating it, but it apparently was not getting that far. You can see the CLICK event firing in the engine monitor...
RUN RUN_EVENT 'SYSPROG*OIWIN', 'RTI_CFG_INET.BTN_SYSENV_REC', 'PUSHBMP', 'CLICK*11*SYSPROG*..OIWIN*'

Any Ideas?

Thanks, Jim

DonBakke

Hi Jim,

There should be no extraordinary reason why the RTI window will not work. The usual culprit for why RTI (or third-party) forms will not work is because of the common practice of naming commuter modules as formname_EVENTS. SRP FrameWorks assumes this convention and the promoted event layer will attempt to interact with any commuter module using this naming convention unless told not to.

The typical solution is to update the Special_Windows section within the Promoted_Events function. Add a check for RTI_CFG_INET and set the EventFlow return argument to EVENT_SYSTEM_ONLY$. Actually, to make life easier on yourself, do this instead:
Case Window[1, 3] EQ 'RTI' ; EventFlow = EVENT_SYSTEM_ONLY$
That way you can manage all RTI name spaced forms with one check.

JimPeters

Hi Don,

Thanks for the quick reply. I had forgotten about that little low-tech problem and was imagining much messier scenarios. It had been 6 years since the last time I had to do anything with that module, which speaks well of it's reliability.

That 'Special Windows' list was rather long and yet it still managed to overlook a few items. Very messy. I decided a better approach would be to just trap the windows belonging to SYSPROG, and then have a very short list to handle exceptions. So I added a couple of lines like this...
Entity_Id = @APPID<1> : "*OIWINEXE**" : Window Entity_App = Repository("GETAPPID", Entity_Id)
And a little farther down at the correct place in the Case statement block...
// Exclude anything belonging to SYSPROG Case Entity_App EQ "SYSPROG" ; EventFlow = EVENT_CONTINUE_NO_PROMOTED$
Much cleaner and everything works!

DonBakke

Hi Jim,

That is a very smart approach. I think I overlooked this because, once upon a time, core FrameWorks forms used to be stored in SYSPROG. Thus your solution would be too successful. But we worked hard to remove everything out of SYSPROG other than SRP utilities (e.g., SRP Editor), which do not rely on promoted events for obvious reasons.

Why did you go with EVENT_CONTINUE_NO_PROMOTED$ rather than EVENT_SYSTEM_ONLY$? Using EVENT_CONTINUE_NO_PROMOTED$ still allows FrameWorks to call the commuter module of the SYSPROG form. This can be problematic as it could cause the commuter to be called twice for an event (once by FrameWorks and then again by the form's Script or Quick event handler.)

JimPeters

Hi Don,

I probably did it that way because of this comment at the beginning of the section...

Special_Windows:
// Special windows should be listed here with the event flow required. Generally, special
// windows should prevent calls to the promoted event handler but allow the system event handler
// to continue as normal (EVENT_CONTINUE_NO_PROMOTED$).

...and no doubt just copied from what was already there.

If EVENT_SYSTEM_ONLY$ is more correct I will change it! :-)

-- Jim

DonBakke

Jim,

D'oh! My own comments betray me!

EVENT_SYSTEM_ONLY$ was added after those comments...after I discovered the very problem I just described! I now need to update the comments.

Hmmm...I am curious if your version of FrameWorks has the EVENT_SYSTEM_ONLY$ equate defined. Please confirm if it is not in your EVENT_SETUP insert. If not, we will need to update your system a bit.

JimPeters

I just looked and I do not even have EVENT_SYSTEM_ONLY$ in my EVENT_SETUP insert, so I must be using a version that predated it. Here is the equates section with the description of what each does...

// Return values to indicate how the event flow should continue. Equ EVENT_STOP$ to 0 ; // Event flow should stop Equ EVENT_CONTINUE$ to 1 ; // Event flow should continue until a later process changes this value Equ EVENT_CONTINUE_NO_PROMOTED$ to 2 ; // Event flow should by-pass the promoted (generic) logic but allow the system event handler to execute Equ EVENT_CONTINUE_NO_SYSTEM$ to 3 ; // Event flow should execute the promoted (generic) logic but stop the system event handler from executing

User: Jim Peters

DonBakke

Jim,

I feared as much. Okay, here is the missing equate:
Equ EVENT_SYSTEM_ONLY$ to 4 ; // Event flow should execute the system event handler only (normal option for third-party windows running in FrameWorks).
In the if/then area that determines of the Commuter Module should be called, the condition should look like this:
// Call the current window's commuter module first for any window/control specific functionality. If EventFlow NE EVENT_STOP$ AND EventFlow NE EVENT_SYSTEM_ONLY$ then
This should bring you up to speed.