This is just one means of linking forms (or parts of forms). If you want to handle your SDI application at the form level or you need your own form handling, there are several ways of achieving this. First, you’ll need to design the window navigation to determine how your application hangs together, and you’ll need to draw up a window hierarchy chart. This will show you which screens call which others and their interdependence. With this type of diagram, you will also be able to determine which screens can be closed and which need to remain open. From here, you can decide the best way to handle the interface and make decisions such as, “Will there be a single parent window?” “Are some branches of the hierarchy modal?” and “How will the application work?”
Note From a nonmultimedia perspective, drawing up a window hierarchy allows you to design and map your transaction scope if you’re using a database. This might also affect your locking strategy, so it’s a useful step to perform, no matter what type of application you’re building.
Let’s consider an interface that is driven from a single parent screen. An example of this could form part of a workflow application. One method of controlling the interface is to create a status property for each form created on the parent form. You can now write to this property from the child forms, holding details such as moves, minimizes, and maximizes.
You can also test for the status of a window by using the Windows API. Several calls return 0 on failure and nonzero on success. Two that you might find useful are IsChild, which determines whether the window is a child of another window, and IsIconic, which tells you whether the window has been minimized. To restore a window from a minimized state, use the OpenIcon call, or change the WindowsState property. I’m sure that with a little thought and planning, you’ll find that you are no longer restricted to the MDI-style interface.