【正文】 the screen, and so on. Windows also supports two types of dialog boxes: modal and modeless. A modal dialog box, once on the screen, blocks input to the rest of the application until it is answered. A modeless dialog box can appear at the same time as the application and seems to float above it to keep from being overlaid. Most simple Windows applications use a Single Document Interface, or SDI, frame. The Clock, PIF editor, and Notepad are examples of SDI applications. Windows also provides an organizing scheme called the Multiple Document Interface, or MDI for more plicated applications. The MDI system allows the user to view multiple documents at the same time within a single instance of an application. For example, a text editor might allow the user to open multiple files simultaneously. When implemented with MDI, the application presents a large application window that can hold multiple subwindows, each containing a document. The single main menu is held by the main application window and it applies to the topmost window held within the MDI frame. Individual windows can be iconified or expanded as desired within the MDI frame, or the entire MDI frame can be minimized into a single icon on the desktop. The MDI interface gives the impression of a second desktop out on the desktop, and it goes a long way towards organizing and removing window clutter. Each application that you create will use its own unique set of controls, its own menu structure, and its own dialog boxes. A great deal of the effort that goes into creating any 沈陽航空工業(yè)學(xué)院北方科技學(xué)院畢業(yè)設(shè)計(jì) (外文翻譯 ) 4 good application interface lies in the choice and organization of these interface objects. Visual C++, along with its resource editors, makes the creation and customization of these interface objects extremely easy. Eventdriven Software and Vocabulary All windowbased GUIs contain the same basic elements and all operate in the same way. On screen the user sees a group of windows, each of which contains controls, icons, objects and such that are manipulated with the mouse or the keyboard. The interface objects seen by the user are the same from system to system: push buttons, scroll bars, icons, dialog boxes, pull down menus, etc. These interface objects all work the same way, although some have minor differences in their look and feel. For example, scroll bars look slightly different as you move from Windows to the Mac to Motif, but they all do the same thing. From a programmer39。s standpoint, the systems are all similar in concept, although they differ radically in their specifics. To create a GUI program, the programmer first puts all of the needed user interface controls into a window. For example, if the programmer is trying to create a simple program such as a Fahrenheit to Celsius converter, then the programmer selects user interface objects appropriate to the task and displays them on screen. In this example, the programmer might let the user enter a temperature in an editable text area, display the converted temperature in another uneditable text area, and let the user exit the program by clicking on a pushbutton labeled quit. As the user manipulates the application39。s controls, the program must respond appropriately. The responses are determined by the user39。s actions on the different controls using the mouse and the keyboard. Each user interface object on the screen will respond to events differently. For example, if the user clicks the Quit button, the button must update the screen appropriately, highlighting itself as necessary. Then the program must respond by quitting. Normally the button manages its appearance itself, and the program in some way receives a message from the button that says, The quit button was pressed. Do something about it. The program responds by exiting. Windows follows this same general pattern. In a typical application you will create a main window and place inside it different user interface controls. These controls are often referred to as child windowseach control is like a smaller and more specialized subwindow inside the main application window. As the application programmer, you 沈陽航空工業(yè)學(xué)院北方科技學(xué)院畢業(yè)設(shè)計(jì) (外文翻譯 ) 5 manipulate the controls by sending messages via function calls, and they respond to user actions by sending messages back to your code. If you have never done any eventdriven programming, then all of this may seem foreign to you. However, the eventdriven style of programming is easy to understand. The exact details depend on the system and the level at which you are interfacing with it, but the basic concepts are similar. In an eventdriven interface, the application paints several (or many) user interface objects such as buttons, text areas, and menus onto the screen. Now the application waitstypically in a piece of code called an event loopfor the user to do something. The user can do anything to any of the objects on screen using either the mouse or the keyboard. The user might click one of the buttons, for example. The mouse click is called an event. Event driven systems define events for user actions such as mouse clicks and keystrokes, as well as for system activities such as screen updating. At the lowest level of abstraction, you have to respond to each event in a fair amount of detail. This is the case when you are writing normal C code directly to the API. In such a scenario, you receive the mouseclick event in some sort of structure. Code in your event loop looks at different fields in the structure, determines which user interface object was affected, perhaps highlights the object in some way to give the user visual feedback, and then performs the appropriate action for that object and event. When there are many objects on the screen the application bees very large. It can take quite a bit of code