Hi Ian,
I've had some of these questions myself!
Clearwin's always_on_top means always on top of all windows, whether they belong to your application or not. I've never found a way of keeping a window simply at the top of the other windows in its particular application (using Clearwin alone – which is more or less the limit of my abilities), although if a window is modal it does stay on top of other windows in the application because they are all disabled until the modal window is closed. You have to be careful, as several things like %mi and %sy allow such a window to be minimised out of the way. However, the main window’s menu stays disabled.
The key is surely sorting out the Z order of windows ... something that is written up in MSDN – but which looked rather difficult when I read it.
Parent and child windows in Clearwin aren't simply 'this window called that one into existence', but rather that a *parent *window operates as a container for other windows (children). Pod and peas seems a better analogy. A typical use of this is for example, a multiple document interface MDI program where each 'document' occupied a separate child window. A strength of the parent-child approach is that one minimise action closes the whole lot, whereas separate windows (with %lw) have to be closed one at a time (or at least, not without a great deal of programming). The child windows can all be clones of each other, i.e. all doing the same job but on different documents, or they can all be different with each performing a different job (like floating toolboxes). The child windows all need their own captions, or you need to use the procedures written up by Jalih for moving his clock by the client area (other thread).
Modern versions of MS Office apps have abandoned the pure parent-child approach as in Clearwin, and do an alternative, which is to spawn a new copy of the application for each document. This reverts to the way Windows worked before it had any MDI applications.
If you go down the parent-child window route (as in Clearwin), you need to keep a copy of all main menu grey codes for each window, as making a different child window active means reinstating its menus as they were last time the window was active. (Not always necessary if the windows all have different functions). You may have to ALLOCATE new data structures each time you open a new child window, and DEALLOCATE them when a child window is closed, in order to make MDI programs work smoothly, or have a fixed number of data structures and a maximum number of children.
Eddie
