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.
Figure 18. Form and window hierarchies
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.
Note: If 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:
FormC:ProWinHandle:PARENT = FormB:ProWinHandle.
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.
