During week 6 we created a window to handlecustomers in a order processing program. We created a stand-alone dll for thecustomer class and a customer list class, and a AppExpert dll for the customerwindow. You were supposed to create a stand-alone dll for an order class and an AppExpert dll for the order window described during week 6. We now complete the project by adding the order dll and order window dll to our project, initialize order list and the order windowin our main window's SetupWindow function. We also fill in the message handlerfor delete customer. The code for adding the window and list is very standard andyou may see the results if you download the completed program.
The message handler for WM_DELETE_CUSTOMER is very simple but worth lookingat.
LRESULT TestwindWindow::deleteCustomer (WPARAM,LPARAM){ _orderWindow->deleteCustomer(); return 1;}The order window is the mediator between the customer list and the order list.Because of this most of the action takes place in this window.
One of the features available in many windows with listboxes is a series of sorts by varies fields inthe listbox. This can be accomplished with one template sort function .
One of the project options available in AppExpert is Document/View. This option allowsyou to build a project that has multiple views of the same data. The built-in document/view classes are more complicated to handle than the ones we have created, but when youfinish updating one window there is the standard function Commit that will update yourwindows. Either the Document/View or our method of building multiple views of a fileare examples of two of the patterns described in our book.
The first pattern, the Observer allows the same data to be view in differentways. In the book, page 293, a list of percentages is presented as a table and two differentgraphs. Borland gives a similar example in its ObjectWindows tutorial. Borland's exampleis a set of lines presented as a graph and as a list of lines. In both cases the data sets arethe same for all windows, but a different view is presented in each window. Your library programwill have book information that might be displayed in different was for different users so the mainwindow that displayes each of the subwindows might be considered an Observer. Notice that with appropriate implementation of WM_PAINT we need no extra structures to create thistype of program.
The data for our order processing program may all be stored in the same file, but differentwindows show different types of data. The data is interrelated, but discrete. Here for examplethe subscript of the customer stored in the order would not be updated by the WM_PAINT command.Orders do not know anything about Customers, so there must be a class that knows aboutboth classes and can make needed changes in Orders. Such classes are called Mediators (page 273).In this case the mediator is the OrderWindow since it knows about both classes and is inposition to handle the changes and display the changes to the orders.