Before designing the order window, which I will leave to you, we have to solve one major problem with our Order class. If we want to save the list of orders, we have to save each order in a file. This leaves us with the problem of how to store the pointer to the customer. While we can write the pointer to a file, it is unlikely that the location in the file will be the location of the customer the next time the file is loaded.
One way to solve this problem is to make a table of pointers which associates each pointer with a customer number. This number can be stored and when the file is read, if the customers are read first, each customer pointer can be recovered by looking up the customer and returning a pointer to it.
An easier way to accomplish this is simply store the subscript of the customer in the order. This accomplishes two things. First it is now easy to store orders and customers since they will return to the same position in the arrray. The second advantage to this is that the orders themselves need not know anything about customers. How will orders update the balance if they don't know about customers? They use a mediator.
One problem with the subscripts is that when an item is deleted, all of the subscripts below that item change. One of the OrderWindow's tasks when it receives a WM_DELETE_CUSTOMER message must be to adjust all subscripts greater than that being deleted, by subtracting 1. The subscript deleted will be replaced by a subscript from the list of deleted customers, and the Order will be marked as having deleted customer.
The order window can be constructed as a dialog window with listbox just like the customer window. It will have a menu that allows the window to add an order and process an order. Process will simply delete the order and send a message to the main window that the order has been processed. Add an order will create an order, add it to the order list, display the results and call on the customer class to update the balance of the person who made the order. This menu will be constructed as a standard menu and displayed in the menu bar of the window. It will also appear in response to a right-button click. This means we will replace the TListBox references with RightButtonListBox. Your order window might look like this.
I used a list box with multiple selection to list the items that can be ordered. Here the list was limited, but if we were to implement an inventory class (we're not) there would not be much work to show this list. Multiple selection allows the user to order more than one item. The customer list is imported (facked here) and displayed in a combobox. Order numbers are computed by the window class and are displayed in a read only TEdit box. This is my new order dialog.
The Order window will contain a pointer to a list of orders and a pointer to a list of customers. It will not need to know anything about the customer window. In addition, OrderWindow will have to keep a list of deleted customers.
When an order is processed, the OrderWindow will check to see if the order's customer is deleted. If that is the case, OrderWindow will check the orders to see if that customer has any orders left. If not the customer is deleted from this local list. You might want an Order class function that returns 1 if the order is for the deleted customer, and 0 otherwise (or vice versa). This function need only get the subscript (from the deleted list) of the customer.
The customer list is also needed by the OrderWindow to provide list of customers in the dialog box for a new order. Actual knowledge of customers need go no further than the OrderWindow, since the Order only records the subscript of the customer.
Testing one component of a large windows project can be difficult if the other components are not available. One of the reasons that it is important complete dlls for any of the structures that are share early in the project, is that these are usually the only classes needed to test the interface components. Design flaws in these structures also show up quickly during the test of components.
Our order window uses both the order list and the customer list, so we have to have these structures completed before we can test the order window. In addition, the customer list is primarily the responsibility of the customer window, so it was developed when that window was developed. We knew that the customer list would be used by the order window, so it was created as a stand-alone dll and is available for our order window tests. The customer window may or may not be ready, but we want to keep our order window tests simple, so we will only use the customer list.
We first identify the places where the order window needs to know about the customer list and what it needs to know. The we identify the messages from the customer window that will be handled by the order window and test our handlers.
Our order window needs to have a list of customers to allow the user to choose a customer and to display the customer part of the order information. To provide such a list we simply add test customers to the customer list when we create it in the main windows SetupWindow function. With this list we can add orders and display the orders in the order window.
One message that the order window has to handle and that it doesn't generate is the delete customer message. The order window has a message deleteCustomer but no way to call it because it is called from the mediator in response to a WM_DELETE_CUSTOMER message. All we need to do here is activate the Edit menu's delete item and in that handler delete one of the customers and then send the deleteCustomer message. For the complete text of the test window click here.
Return to Week 6.