Visual Basic has a mixed bag of window-management tricks, the simplest of which are MsgBox and InputBox. These are modal dialog boxes, so you must deal with them before the program will remove them and continue its processing. There isn't much to say about MsgBox and InputBox except that they are inflexible. In particular, you can't change the button captions, and you don't have complete control over size and position of the dialog boxes. For added flexibility, you can, of course, write your own Visual Basic functions named MsgBox and InputBox to override the Visual Basic ones. Interestingly, doing this allows you to make nonmodal message boxes, the consequences of which will become clear later.
Visual Basic also has features to support multiple-document interface (MDI) applications, and the decision to build with MDI will have a major influence on the way your application works. MDI has some advantages-chiefly that it is well defined and that Visual Basic will implement some of the features for you (menu management, window arrangements, and so on). On the other hand, adopting MDI for these reasons alone is futile if the application you want to build doesn't fit the rigid MDI model. MDI supports a document model and usually makes sense only if your application is going to work with multiple instances of things that are somehow document-like. Document-like qualities include serialization (binding to permanent storage) and size independence, which gives meaning to the familiar MDI window-arrangement functions Tile and Cascade.
On the other side of the fence from MDI is single-document interface (SDI). Because Visual Basic has no specific functions to support SDI, however, a more accurate description would be "not MDI." You have much more flexibility when building non-MDI applications, but you lose out on some of the free functionality such as window arrangement, child window menu handling, and Ctrl+Tab to switch between child windows. On the other hand, you have more control over your application's appearance, and you can choose whether to make your child forms modal or modeless.
Finally, you can build hybrid applications that borrow some features from MDI without using built-in functionality. You can, for example, create multiple instances of an ordinary form (forms behave just like classes in many ways), and you can even create MDI parent forms dynamically within a non-MDI application. It's important to consider these issues in advance and to plan a window-management scheme appropriate to the application you want to build.