Welcome to the SRP Forum! Please refer to the SRP Forum FAQ post if you have any questions regarding how the forum works.
SRP Close (Cancel) button will occassionally crash for multi-instance forms
Hi team
This issue only seems to happen for multi-instance forms. These forms are also running as MDI children, although I don't think this is relevant.
We use an SRP Button as an option to close all our forms via the SEND_EVENT(window, 'CLOSE') function. This works fine most of the time, however occasionally (maybe 1 time in 20) for these multi-instance forms OpenInsight will crash. Unfortunately I can't get it to happen on-demand, however if I replaced the SRP button with a OI one instead, the crashes do not occur.
We have setup all controls to run as asynchronous and use the SRP Frameworks promoted events logic (i.e. all non-control specific events come through the PROMOTED_EVENTS routine).
User: James Birnie
This issue only seems to happen for multi-instance forms. These forms are also running as MDI children, although I don't think this is relevant.
We use an SRP Button as an option to close all our forms via the SEND_EVENT(window, 'CLOSE') function. This works fine most of the time, however occasionally (maybe 1 time in 20) for these multi-instance forms OpenInsight will crash. Unfortunately I can't get it to happen on-demand, however if I replaced the SRP button with a OI one instead, the crashes do not occur.
We have setup all controls to run as asynchronous and use the SRP Frameworks promoted events logic (i.e. all non-control specific events come through the PROMOTED_EVENTS routine).
User: James Birnie
Comments
In addition to Kevin's question and comment, I have two questions:
Also, as you probably know, you should always return a 0 (EVENT_STOP$) within the commuter module in this situation to avoid additional processing of code while the form is in the process of being destroyed.
Thanks for the really quick responses! Kevin, yes the event is asychronous, as you mentioned it will crash OI if its synchronous. The only events we have setup as sychronous are edittable related:
OLE.PosChanging
OLE.BeforeUpdate re: crash, its a low level blowup - it would have been a blue screen in the good old days. The windows exception/debug message appears, followed by OI + Oengine closing after pressing ok. The debug info. indicates its a memory-related access violation, which makes sense.
re: post-event, I can't recall exactly why we aren't using this, we did intially. From memory its because it doesn't work in all scenarios - I'll set it back to POST_EVENT and let you know if the error still occurs anyway. I'm guessing it didn't fire when the event chain was already a bit lengthy e.g. via 1 ore more previous dialog call and then something else returns valid = false$ before it gets down to our POST_EVENT -> CLOSE event.
It's strange the error doesn't happen everytime and only for "multi-instance" forms (which we've only recently started using more frequently, hence why we haven't seen this error before).
User: James Birnie
Quick update, I've confirmed the issue still occurs using POST_EVENT
User: James Birnie
I am pretty certain that the fact this form is multi-instance is a red herring, but for the sake of discussion, why do you think it is relevant?
Would you mind posting the relevant code in your OnClick event here? Also, if you swapped the ProgID for the SRP Button control out for SRP HyperLink control and trap the same OnClick event, do you see the same crashing going on? (Hint: I would expect you would, but how knows...)
Thanks again for the reply. Relevant commuter code below (I've removed the irrelevant stuff) where BTN_CLOSE is the SRP.Button.1
compile function oryxadm_workflow_action_events(focus, event, param1, param2, param3, param4, param5, param6, param7, param8, param9, param10, param11, param12, param13, param14, param15) valid = true$ window = field(focus,'.',1) control = field(focus,'.',2) begin case case control = '' begin case case event = 'CLOSE' gosub close end case case control = 'BTN_CLOSE' if event = 'CLICK' then gosub close_job end end case return valid ** eof ***** close_job: send_event(window, 'CLOSE') return close: job_no = oryxctl_get('EDT_JOB_NO') is_changed = get_property(window, var_changed$) if is_changed then gosub send_job_change_event end returnre: multi-instance - it is only these type of forms where we see this behaviour, all of our other forms (probably 95% of which are single-instance) never crash in this manner.
Yep you are right, the same thing happens for the HyperLink control.
User: James Birnie
I will attempt to duplicate using the essence of your code, but I still recommend setting valid to false$. This is rather important in FrameWorks due to the promoted event architecture.
I added return false$ to both areas of the close commuter sections above - but I can still get it to crash as regularly.
Interestingly, the crash is most consistent after I've opened say 5 instances of the same form (via
childid = start_mdichild(formName, parent, createparam, '', '', newWinState)where parent = the main mdi form, and newWinState is generally 1 (normal))So the forms are layered on top of one another and I quickly click-close them all via the SRP.Button, starting with the *first* instance that was opened. It may still crash when closed in reverse order of opening, however it just doesn't seem quite as common (perhaps a third as often).
Hopefully this helps somewhat... please let me know if I can help with any other info. or tests.
User: James Birnie
Post_event seems to work though I can't say I've deliberately opened many multiple instances of a window to test the continual operation.
In the case of dialog_boxes (and I generally know which windows are going to be dialogs), I place an invisible OI button on the form and the SRP button does a post_event(OIButton, 'CLICK') and then the OI button does the close and return logic.
Dialog_boxes are where I had the more regular crashes.
Like I said at the start though, perhaps changing my button events to asynchronous might have fixed the problem anyway. I don't remember if I tried that. I just sort of found something that worked and have stuck with it.
Thanks for the input! I'll give synchronous events a go + do some more tests when I get a bit of free time. From memory it was dialogs that caused us issues as well. This issue may even be a similar, just not as frequent because of the asynchronous nature. It's hard to tell if this conjecture has merit though.
A hidden OI button sounds like a good way to go as another workaround. Currently to stop the occassional crashes I am using an OI button for Close for these few forms affected (which has not crashed for over a week now). This doesn't aesthetically look as great of course, so a hidden button should solve this issue too. I'll let you know.
Thanks again.
User: James Birnie
Alas using the technique described by Mark didn't work - I would still get the occassional form crash when clicking the "Close" SRP.button (which would fire the CLICK event for the OI button), which is leading me wonder if its related to the OnClick OLE event (which goes back to the commuter, possibly combined with the CLOSE event of other form instances perhaps (maybe @window can get out of sync perhaps, when using the controls in async mode?). It's hard to tell without building some sort of logging of all this is going on.
So for now, its back to the old OI button for close of these type of forms, until I can really dig into what is going on/when during a crash.
User: James Birnie
I don't want you to think that I forgot about you. I have been personally caught up in some intensive projects and am just now coming back up for some air.
I realize your symptoms continue to persist, even if you change the control to something else, but I still cannot replicate the problem. I added an SRP Button control to a multi-instance MDI child form. In the commuter module the code does this:
Case Control EQ 'PUB_TEST' Begin Case Case Event _EQC 'OnClick' Send_Event(@Window, 'CLOSE') EventFlow = EVENT_STOP$ End CaseI have successfully launched 10-15 instances of the MDI child window and closed it with the button many times in a row. I really don't know what to offer you at this point. If you are eager to send me a copy of your system (feel free to strip it down as much as possible) then I would be willing to do some in-house testing.
Even though this has not helped your situation and others (like Mark) have suggested they do something else, I would like to emphasize the following best practice concepts:
Thanks for the update, and for looking into it, I appreciate it. And thanks for the advice, I'll revert to using POST_EVENT for the SRP buttons. I can confirm that swapping it back to an OI button definitely avoids the crashes.
Cheers,
James
User: James Birnie
Assume you are calling the same code from within your commuter module with the OI button versus the SRP Button (i.e., you are not using the QuickEvent to CLOSE the Window), this makes me highly suspicious that you have other OLE event code executing. Are you sure there is no promoted OLE event that might be involved?
Yep its the same code, but there is no other OLE event that I am firing via code. We do have a promoted OLE event (within PROMOTED_EVENTS) which also checks for an internal form error (@variable within the form) to avoid the firing of the OnClick event in cases where there is an error within a field (e.g. LOSTFOCUS_PRE) however I don't see how this could cause an issue. Happy to post this code if helps though?
My suspicion remains that due to the asynchronous nature of the events when quickly closing them that something is occasionally getting out of sync and fires for one of the other windows that has already closed (e.g. when testing I would layer all the forms directly one on top of each other - say 10, then as quickly as I could I was clicking the "Close" button, this would result in an AccVio perhaps 1 in 3 times).
User: James Birnie