Parent forms and windows to each other
- Last Updated: January 17, 2024
- 3 minute read
- OpenEdge
- Version 12.8
- Documentation
ABL allows you to link non-modal windows in a hierarchy by setting the PARENT attribute of a child window to the handle of its parent window, and allows you to repeat this for as many child windows as you want using any window as a parent. When a parent window in such a window hierarchy is minimized, all of its child windows (and their descendents) are hidden. Also, if you delete the handle of a parent window, the handles of all its child windows and their descendents are deleted.
.NET allows
you to link non-modal forms in a similar hierarchy by setting the Owner property
of a child System.Windows.Forms.Form to the object
reference of its owner (parent) form, or by passing the object reference
of a child form to the AddOwnedForm( ) method
of its parent form. For form hierarchies, child windows (and their
descendents) are also hidden when you minimize a parent form. In
addition, form hierarchies have a feature not available with window
hierarchies, which is that child forms never display behind their
parent form. Within .NET, the deletion of form objects in hierarchies
is handled by .NET garbage collection.
In an ABL session,
you can set up these separate hierarchies for non-modal windows
and forms using the PARENT attributes of windows
and the Owner properties or AddOwnedForm( ) methods
of forms. Each hierarchy then behaves in its native ABL or .NET fashion.
In
addition to these separate form and window hierarchies, ABL allows
you to create mixed form and window hierarchies by parenting to
each other the non-modal ABL windows that you create and the shadow
windows that ABL creates for non-modal forms. In order to create
such a mixed form and window hierarchy, you must instantiate the
form objects as Progress.Windows.Form objects (notSystem.Windows.Forms.Form).
This allows ABL to create the required shadow window for each .NET form.
(For more information on shadow windows, see ABL session architecture for forms and windows.)
To create a mixed hierarchy, you can then use the PARENT attributes
of the non-modal ABL windows and form shadow windows to set up the
parent-child relationships between them in any combination. This
mixed hierarchy then behaves much like a pure ABL window hierarchy.
The following figure shows a mixed form and window hierarchy and the PARENT attribute assignments used to set it up.

This figure
shows a hierarchy consisting of a form (FormA object
reference) that is the parent of a window (WindowX handle),
which is in turn the parent of both a window (WindowY handle)
and a form (FormB object reference). Each of the
three parent-child relationships appears with a line of sample ABL
code that sets it up. For example, to make FormB a
child of WindowX, it sets the PARENT attribute
of the FormB shadow window (referenced by the ProWinHandle property
of FormB) to the handle of WindowX, and
so on.
WindowX is a window
handle (as shown), WindowX:HANDLE is a valid reference
to the ABL HANDLE attribute, but is redundant and
shown here only for clarity.You can also parent a form
to a form within a mixed hierarchy this way. For example, like adding
a FormC as a child form of FormB in the above figure:
|
Minimizing the parent of a mixed form and window hierarchy works the same as for a separate form or window hierarchy. Also, if you close a parent form with child windows, the AVM deletes all the connected windows in the hierarchy, as with deleting a parent window in a pure window hierarchy. However, for a parent window with a child form, deleting the parent window does not automatically delete its child forms in a mixed hierarchy. You must handle the closing and deletion of these child forms yourself.