At this point you may want to sketch a possible interface. You will learn to compare this interface with what users currently do , but you still need to have some idea of a starting point.
The main form will mainly have a pull down menu for rental and for windows. The windows menu will allow the user to show or hide the Customer and the Rental windows. This menu will be dynamically changed so when a window is hidden, the text of the choice will change to Show &XXXXX. Notice since show and hide are not fixed, you will make the shortcut the first letter in the window type. This version assumes that the rental window will start showing and the customer hidden.
|
|
The hide and show functions are very similar for both forms. For each form you create a bool variable _xxxVisible. This is set true or false depending on whether the window starts visible or not. The menu hander just calls Show or Hide and resets this variable. The one new feature is the dynamic change in caption for the menu. This is done with a simple assignment. void __fastcall TMainForm::HideRental1Click(TObject *Sender)
{
if (_rentalVisible)
{
_rentalForm->Hide();
_rentalVisible = false;
HideRental1->Caption = "Show &Rental";
}
else
{
_rentalForm->Show();
_rentalVisible = true;
HideRental1->Caption = "Hide &Rental";
}
}
The mainform is reduced to a strip that will appear at the top of the screen. |
|
The rental form is a window used to create new rentals. It must collect all of the information needed to complete a rental transaction. One of the most important pieces of information is the customer id. This may be supplied by the customer, but more likely the customer will not know it. Even if the customer knows their number, the user must check the customer information. A box for the customer id is provided with the hope that it will be available, but the Check Customer button must be used to bring up a customer window to confirm information in all cases.
It's not to early at this point to think about what you will require before you allow the confirm button to be pressed. Not only that, what if the customer wants to make more than one reservation? Does the user need to reconfirm the customer information? Probably not. Make a list of those fields that must be filled and/or confirmed before the reservation can be completed.
Another question that will have to be answered is whether to hide or disable items such as the Boat Slip Length when they are not needed (when a room rental is being processed).
| You will not want this window to be resized, so in the Object Inspector, under Border Icons remove all of the icons except for the system menu. |
|
Once again you need at least one way to enter each piece of information for the customer. In addition this window must provide a mechanism for looking up customer information. If the id is not provided, a list of all customers with the same last name and zip code (or name and telephone number) must be retrieved. The Summary window may be used for any type of lookup. The user can either select an entry from the summary window or if no correct entry is listed, create a new customer.
|
At this point, you want to stop and make some preliminary decisions about the type of component you want for each of the items in the dialog. You have no idea what form names (last, first and city) and street addresses will take, so you will use TEdit boxes for these fields. States are relatively constant, so you may want a combobox with all states listed. You can use the text part of this box to allow the user type the state code. The main problem with this is that most people don't know the post office abbreviation for all of the states. To ensure that you get the correct abreviation, you will need to check typed data with the data listed. You will probably store the actual abbreviation rather than the index of the item since this will make printing information easier.
Once you get to the phone and zip code, you will want the information to take a constant form. The Edit Mask is the appropriate component to retrieve this data, since most commonly formated information has a prepackaged edit mask.
Finally, the summary should hold both text summaries and lists of people. The best component for this is the listbox, since you can set the items text directly and each line may be selected with a click of the button.