I'm still at odds with this new property as I can't see why a behavior that has been there (and intended to be the way) since the beginning of MFC has to be circumvented.
Is there a problem when a hidden modal form goes out of scope? Is it not getting deleted automatically?
I would like to bring this one up again.
According to the OpenEdge documentation (documentation.progress.com/.../index.html and StackOverflow/Microsoft (stackoverflow.com/.../3097383, a Form that is not shown modally, gets disposed on Close(). When the Form is shown modally (i.e. ShowDialog()), the Dispose does not happen automatically and you need to call Dispose() yourself.
Progress thought it would be helpful to provide a way to by default have the Form dispose when it's closed as Dialog as well.
While this seems reasonable, there is a bug in the implementation:
In the Microsoft implementation, when closing a non-modal Form, the Dispose happens AFTER the form has closed (i.e. after OnFormClosed())
In the OpenEdge implementation of DisposeDialogOnClose, when closing a modal Form, the Dispose happens INSIDE the OnFormClosed() method of Progress.Windows.Form.
This can be seen by looking at the stack trace when overridding OnFormClosed and subscibing the Disposed event of a Form and closing the screen.
This causes code that uses the FormClosed event of the Form to no longer be able to access properties of the Form when started as dialog, while still being available when started non-modally!
In my particular case I'm saving some screen settings in FormClosed, and this fails when the same Form is shown as dialog, since the form is already disposed...
I'm trying a workaround now by setting DisposeDialogOnClose to false, and calling the Dispose() method myself at the very end of OnFormClosed(), but that will still cause problems for classes inheriting from my base form class...
Cross-posted at: community.progress.com/.../36748