We have now seen two ways of combining windows, sw_dest() and sw_parent(). In both cases, dragging windows and bringing windows to the top are handled automatically by Vermont Views. The Vermont Views window management takes care of these issues.
There are specific differences in these two approaches. While sw_dest() sets one window on another window's buffer, sw_parent() sets a window within another window's work area.
There are advantages and disadvantages to each approach, and the needs of your particular application will determine which method is best for you. The following list of differences between the two approaches may help you make a decision.
| 1 | A child window and its parent's buffer are completely independent, so you do not have to worry about overwriting a child window. When writing to the parent window, the output is written underneath the child. If the child window is later removed, dragged, or resized, the data that was written underneath the child window will automatically appear in the proper place. As the user scrolls through the contents of the parent window's buffer, the child window does not move. Its position is relative to the parent window's interior work area, not to the contents of the parent window's buffer. |
| In contrast, sw_dest() links one window's output to another window's buffer. This causes the window to maintain its position relative to other items in the buffer as the buffer scrolls. From a user's perspective, this makes the sub-window part of the larger window, rather than sitting on top of the larger window the way a child window does. | |
| 2 | Output to a child window is automatically echoed to the screen. There is no need to manually update regions of the parent window. When a child is taken down, the underlying region of the screen is automatically updated from other children or from its parent. |
| Output to a sub-window set on another window's buffer with sw_dest() updates that memory screen buffer directly. Vermont Views does not know how many windows are using that memory screen as a buffer, or which of those windows you want to update on the screen. It is therefore your responsibility to update the screen (if necessary) after writing to a window that has been set on another window's buffer. To do this, you can call wn_upd() or wn_updrgn(). Remember that you must update the window that uses the memory screen as a buffer, not the window that uses the memory screen as a destination. | |
| 3 | Child windows can be moved and resized within the parent window. Vermont Views window management will automatically handle overlapping child windows, child windows within child windows, etc. |
| In contrast, when you link a sub-window to another window's buffer with sw_dest(), you are responsible for making sure that the sub-window always lies completely within the buffer. Also, if the sub-window is moved, resized or removed, Vermont Views has no information available to redraw uncovered regions of the buffer. The uncovered regions will be cleared with the memory screen attribute. This can be hazardous to information in the buffer and to the appearance of any window using the memory screen as a buffer. | |
| 4 | Child windows and parent windows can be activated, suspended, scrolled, etc. independently of each other. |
| 5 | Child windows can be set on any kind of parent window, not just those with memory screen buffers. |
| sw_dest() can link a window to any memory screen, not just one that is acting as another window's buffer. | |
| 6 | The parent cannot be changed for any window that is currently set on the screen. |
| In contrast, a window's destination can be changed at any time. |
