End_Dialog and End_Window, a Cautionary Tale

275px-SRP_Editor_500pxBelated Happy New Year to everyone. Project demands for SRP ramped up significantly at the end of 2013 and has carried over to 2014, which is why we are late in contributing to our blog as well as getting our next newsletter out. There are some very interesting product updates that we are excited about. Therefore, we hope to refocus on our publications shortly.

In the meantime, we wanted to share a quick reminder about the potentially unwanted, or unexpected, behavior of the End_Window and End_Dialog system stored procedures. We ran into this during a recent project wherein we have been retrofitting a 15-year old OpenInsight application with the latest version of SRP FrameWorks. One of our standard features is to add the caption of an MDI Child form to a clickable list of names (aka Open Windows) along the left side our our MDI Frame:


The purpose of this list is to help end users remember which forms are already running and to give them an easy way to bring forward the form they wish to work on. Naturally, we automate all of this through promoted event handlers, specifically CREATE (to add the caption to the list) and CLOSE (to remove the caption from the list.)

During our recent upgrade project, we began to notice that several of captions remained in the list of Open Windows despite the fact that we dismissed the forms. It didn’t take long to realize that it made a difference in the way we dismissed the forms. Specifically, if we used the form’s system menu close button then everything worked as expected. The problem only occurred when we clicked on the form’s push button which was intended to close the form. Further investigation led to the discovery that the CLICK event handler for these buttons used the End_Window function.

End_Window is a perfectly acceptable way to close a form. It even provides a convenient argument to direct focus to another form and control after the form is closed. So why would this have an impact on our Open Window list management? The simple explanation is that End_Window (and End_Dialog) do not close forms using the CLOSE event handler chain. Rather, they utilize the DESTROY service. Consequently, any CLOSE event handlers (including scripts) are bypassed, thus ignoring any form specific or application wide logic that is required when closing the form.

Of course, the developer might actually want to bypass the CLOSE event handler. Barring that, the natural question is, “How do I resolve this?” That will depend on the nature of the application and each form. End_Window itself can generally be replaced with a Post_Event call:

Post_Event(@Window, ‘CLOSE’)

End_Dialog, however, is the recommended method to close a form launched with the Dialog_Box or Create_Dialog functions. In these situations it might be best to directly call any logic that would otherwise be handled by the CLOSE event handler. This, of course, makes a strong argument for writing code that is modular and loosely tied to any specific event handler. As in our situation, the logic that maintains the Open Windows list is stored within a callable routine rather than directly embedded in our respective promoted CREATE and CLOSE event handlers. We can call this routine at will whenever the situation requires it.

3 Responses to End_Dialog and End_Window, a Cautionary Tale

  • Colin Rule says:

    This is an area that often catches me out. I want to close a window in my code, but closing within the code is risky, with labeled common message being a common occurrence. Post event is something I use often.

    I have however had occasion where there are possible problems with this, such as when running a dialog from another dialog. Things can fail or act with unexpected results.

    A solution that I have used (very) occasionally, is to close the window via a differend method.
    Within the window code you want to close, I do a PostEvent or SendEvent to my parent form, with a message to close the Window I am in. This can then run the EndDialog or whatever I choose, and it then closes the window, without me having to code around the close within my form.

    Not always logical, but it has worked on the odd occasion where I have had issues.


  • Don Bakke says:


    I don’t often have dialog boxes calling other dialog boxes except for Message Boxes and Popups, which ultimately get called as dialog boxes. I have yet to see a problem with the way they close.

    Your workaround, however, is interesting. Basically, you are forcing the parent window to shutdown the dialog box in order to avoid having remaining event logic executing after it is closed. This is, of course, the same principle as using the Post_Event(@Window, ‘CLOSE’) solution. So we get back to why you encounter problems when doing a traditional close. I will have to see if I can duplicate your experience. I take it that the symptoms vary?

  • Colin Rule says:

    I have a form which I launched by Dialog_Box, which itself launches several other forms.
    When I close the second form, there were problems with events not being triggered.
    I cant actually recall what form this was to investigate again, and advise in detail.
    If I find it, I will advise.

    Another situation where I use this concept is with a form which I use an Ole Panel control on the right of the screen. In this case I dont want the form to close under some event. But when the same form that I add in panel is launched as a separate form, I do want it to close, so I can do this via the Parent.
    There are probably other ways, but it works for me in this case.

    I was just adding to the comments in case another user has a similar need.
    I dont expect the issue to be fixed by Revelation, as I am using OI8 and it may not even be an issue any more.


Leave a Reply to Colin Rule Cancel reply