Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
Possible bug in OI?
I have been running into a quirk with Openinsight and wanted to see if it is a known bug and some possible ideas on a work around.
I currently have promoted general event code that bypasses the need to tie Quick Events to my commuter modules. The only problem I am having is with the OPTIONS event. It appears when the OPTIONS event is fired, that it will check to see if there is any Quick Event defined for OPTIONS in the control - and if no Quick Event is there, it pops up a message that no options are available. The OPTIONS event seems to be unique from other Events with this internal error message.
The only work around that I've been able to come up with at this point is to make an OPTIONS Quick Event calling the commuter module. Is there any ideas on how I can suppress this "No options are available" message? Another thought I had was to create a Control Type Specific promoted event handler and return a zero value to avoid processing where the message is getting generated, but I haven't tested that out yet.
I currently have promoted general event code that bypasses the need to tie Quick Events to my commuter modules. The only problem I am having is with the OPTIONS event. It appears when the OPTIONS event is fired, that it will check to see if there is any Quick Event defined for OPTIONS in the control - and if no Quick Event is there, it pops up a message that no options are available. The OPTIONS event seems to be unique from other Events with this internal error message.
The only work around that I've been able to come up with at this point is to make an OPTIONS Quick Event calling the commuter module. Is there any ideas on how I can suppress this "No options are available" message? Another thought I had was to create a Control Type Specific promoted event handler and return a zero value to avoid processing where the message is getting generated, but I haven't tested that out yet.
Comments
That is the exact issue we ran into with FrameWorks once we eliminated all dependencies upon QuickEvents. This is not a bug in OI as much as it is a design decision. By the way, you get the same problem with the HELP event.
Remember, the OPTIONS event (and the HELP event) are not real events in the sense that they are connected to some activity within the environment. Thus, they are not physical events. They fall under the category of programmatic events. Fundamentally, they are merely placeholder events to make it convenient for OI developers to hook code up to. In fact, I think they only exist to help AREV developers make the transition.
When you call these events, first OI will see if a script event handler exists. If so, then it will call it in the normal way. There is no System event handler so it goes directly to the QuickEvent Handler. All QuickEvent Handlers are managed by by the SYSPROG generic event handler, which is the "end of the line" of the event chain. The logic simply attempts to process anything defined in the QuickEvent. If there is nothing defined then it produces the message you have been seeing.
Personally I think the message should have been eliminated and the developer would get an error flag (if checked) so anything could be done at that point. Since this is not the case, we are forced to work around the issue.
The best solution, IMO, is similar to your last suggestion. Make your own promoted OPTIONS event and return a zero. However, within this code you should automatically call your commuter module so you can get those OPTIONS event to properly trigger.