A control always belongs to a particular floating window and cannot be displayed outside that window (however, some controls, such as combo boxes, can temporarily pop up information outside of the floating window). Like all screen elements, controls are positioned relative to the current subwindow. When you destroy a floating window, all controls that belong to that window are also destroyed.
Controls and pop-up subwindows do not interact well on some systems. The reason for this is that graphical controls are native elements of the host system, while subwindows are a text-only construct created by the ACUCOBOL-GT runtime system. Because the host graphical system is not aware of ACUCOBOL-GT subwindows, the system unwittingly displays controls over subwindows. Unfortunately, such host systems do not have support for a construct similar to ACUCOBOL-GT's subwindows, so the subwindows must be managed directly by the runtime system.
To avoid problems, you should not use controls in any location that may intersect with a subwindow. If you are upgrading an existing program to use controls, you should start by converting any subwindows to floating windows. Floating windows interact correctly with controls, and have the added benefit of having generally better functionality (for example, the user can move them with the mouse).
Another peculiar interaction between controls and windows may occur in the case of the scrolling windows. This behavior occurs on both the Windows and character-based systems. The controls on a scrolling window 'move' properly as you scroll the window; however, if the window is subsequently covered up and re-displayed, the controls are re-displayed in their original locations, which may be inconsistent with the current re-display of their host (scrolling) window. The behavior in this case is undefined.