Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
ACTIVATED event is "hijacking" my commuter module-based form
I like centralizing my logic into fewer modules, so I am transitioning a form that I call with DIALOG_BOX() away from using repository-based event handling towards using a commuter module.
As I have cleared out the event scripts and moved everything to FORMNAME_EVENTS with its big case statement, I am experiencing an unexpected pathology with the ACTIVATED event.
Previously I had just ignored the "ACTIVATED" event and put all my init logic under EVENT = "CREATE".
I had assumed CREATE would be called first no matter what; so, I assumed ACTIVATED could be safely ignored still. Or, failing that, ACTIVATED might be called first, but then if I returned properly, CREATE would be passed in next.
This is not working out. What I see instead is that EVENT= "ACTIVATED" is passed in exclusively, both when the window is first created (!) and every time it is touched. "CREATE" is never passed in at all - or at least, I can't "catch" OI doing it.
Thus, the form is never initialized because case EVENT = "CREATE" is where my init logic is. I tried putting return 0, then and return 1 in the commuter module for ACTIVATED, but the issue persists.
Again, this wasn't an issue when I was relying on Windows events in the repository.
Why is this happening, and what is the best practice? How do I get OI to pass me my CREATE event so I can initialize my form and get on with the rest of the logic?
As I have cleared out the event scripts and moved everything to FORMNAME_EVENTS with its big case statement, I am experiencing an unexpected pathology with the ACTIVATED event.
Previously I had just ignored the "ACTIVATED" event and put all my init logic under EVENT = "CREATE".
I had assumed CREATE would be called first no matter what; so, I assumed ACTIVATED could be safely ignored still. Or, failing that, ACTIVATED might be called first, but then if I returned properly, CREATE would be passed in next.
This is not working out. What I see instead is that EVENT= "ACTIVATED" is passed in exclusively, both when the window is first created (!) and every time it is touched. "CREATE" is never passed in at all - or at least, I can't "catch" OI doing it.
Thus, the form is never initialized because case EVENT = "CREATE" is where my init logic is. I tried putting return 0, then and return 1 in the commuter module for ACTIVATED, but the issue persists.
Again, this wasn't an issue when I was relying on Windows events in the repository.
Why is this happening, and what is the best practice? How do I get OI to pass me my CREATE event so I can initialize my form and get on with the rest of the logic?
Comments
I assume "repository-based event handling" refers to script event handlers. Even commuter modules are called via the Repository so that description is a little ambiguous.
You are correct that the ACTIVATED event does get called before the CREATE event but they are not chained together. I guarantee you that the CREATE event is getting called. My first guess is that you still have a CREATE script event handler in your repository and it is returning 0, thus the event chain fails to move forward and call your commuter module (which I presume you are calling using the QuickEvent).
Should I visit the other script event handlers in the repo and make them all return 1 as well then...? I admit I'm not always clear if I'm fighting my lack of understanding, or flakey behavior in OI, when it acts in unexpected ways.
For example, I selected the OK button in this form and set its CLICK quick event to Call Commuter Module, then I saved it.
Then when I came back to the form, I found that that "Call Commuter Module" wasn't selected anymore, but rather "Execute a procedure." There's no way I can keep "Call Commuter Module" selected. The moment I leave the form and come back it's changed to "Execute a procedure".
Shouldn't "Call Commuter Module" stay selected once I choose it?
I this scenario, I suspect part of the problem is a lack of knowledge of how OpenInsight manages event handlers. This is a topic that is covered relatively well in the Introduction to OpenInsight training course. However, the gist of this topic is also covered in the first few paragraphs of our Promoted Events whitepaper. I recommend you review it.
The way you will resolve your problem depends on whether you are updating an inhouse system or whether you are updating a deployed system. In the former case, the best solution is to properly remove the script events. This will avoid them being called in the event chain and thus your QuickEvent will get called automatically.
In the latter case, you might not have the luxury of removing the script events. Thus, your best bet is to update the script events in your development environment to "Return 1" and deploy them. This will to ensure that the QuickEvent will get called.
It is understandable to expect this to be the case. However, there is a reason why it doesn't. All that happens when you select "Call Commuter Module" is that the system configures the QuickEvent to "Execute a procedure" with the target being "SYSPROG*STPROCEXE**OBJ_CALL_EVENT". Thus, when you leave and go back, it doesn't record the fact that you once clicked "Call Commuter Module". All it knows is that it is calling a procedure called OBJ_CALL_EVENT. Personally, I think it should be smarter and keep "Call Commuter Module" selected, but this is the way Revelation designed the Form Designer...for better or for worse.
The app is in development, so I'm free to change how I did the windows logic however I see fit.
I can see the field where the event handler names are kept (field 6 I guess, not 21 as in the paper?).
So, I can
* edit them in the Windows Designer, clear out the logic and put Return 1 in them.
* Or, I could clear out the values in this Window field, go to the SYSREPOSEVENTEXES table and delete these records as well, and then the commuter module will be called cleanly from Quick Event.
Is there a current Conventional Wisdom (TM) regarding using the commuter module approach vs script event handlers? Personally I like centralizing logic into the commuter module, but I am open to advice from people with more experience. What is easier to maintain long term?
The proper way to remove your script events is to go to the Event Script editor from within the Form Designer then click on Edit > Clear Event:
Then click on File > Exit/Update and recompile the form. This alone will completely remove the script event from the repository.
Do NOT change the RETURN 0 to RETURN 1 or add anything else here. Otherwise you wind up adding back the script event that you just removed.
You are definitely on the right path. Stay away from script event handlers as much as possible. Commuter Modules are what we (and the majority of the developer community I believe) consider to be "best practices". This is why OpenInsight 10 has added more support for QuickEvents/Commuter Modules than exists in OpenInsight 9.
That said, unless you engage in other techniques (which I'll summarize further below), you will have to use script events in some cases. For instance, if you need to capture the WRITE event before the System Event handler, you will have to use a script event for that. Nevertheless, you can still write the code in your commuter module and simply have the script event handler call your commuter module. This compromise still allows you to maintain all true event logic in one stored procedure.
Since you are interested in additional advice I'll offer two more items for your consideration.
First, consider using promoted events. You have the white paper we wrote on the topic. This will give you a way to create a foundation (or what we call "framework") for event management that will add tremendous value. It will also give you a way to avoid having to rely upon script event handlers. Just have your promoted events call your commuter modules and never have to rely upon the Form Designer's QuickEvents or Script Events ever again.
Second, consider using our Enhanced BASIC+ syntax for commuter modules. This requires you to install our free SRP Utilities library, but the end result is a far more streamlined commuter module. The SRP Editor will provided a more enhanced experienced with commuter modules, but this is a commercial product and therefore is optional.