An Invoicing Application

Team Fly

Page 516

first instance of the application and try to retrieve the new product. You can search for it by name, category, or supplier. If the new category doesn't appear in the ComboBox of the auxiliary form, close the auxiliary form and open it again. The application will fail to load the selected row, because it violates the DataSet's referential integrity. This will activate the Catch clause of the structured exception handler shown in Listing 18.3, and the application will silently reload the Categories and Suppliers DataTables.

You can't delete any products from the database, because they're all referenced by one or more rows of the Order Details table. You will be able to delete a row in the DataSet, but the update operation will fail. Start two instances of the application and add a new product using one of two windows on the desktop. Then select this product in both instances of the application. Delete the product in one instance of the application, and then edit it in another instance of the application. The deletion will succeed, but the edit operation will fail, because the application can't find the row in the Products table and update it. When you click the OK button for the first time, the changes will be submitted to the database. When you click the OK button of the other instance of the application, the update operation will fail. You must cancel the edits and reload the same product row to see the current values of the row in the database. This happens because the DataAdapters were configured for optimistic concurrency. If you turn off optimistic concurrency, then all changes will be written to the database, overwriting changes made by other users.

A very common task in business applications is a program for entering orders and invoices. All invoicing applications are based on a grid control, where the user can enter, as well as edit, the items. If you attempt to build an interface for an invoicing application with the DataGrid control, you'll end up writing a lot of code to add functionality that's not natively supported by the control. A basic requirement of an invoicing application is that it should provide full keyboard support. Can you imagine a cashier at the Wal-Mart using the mouse? Of course, Wal-Mart doesn't use Windows workstations at their registers, and there's a very good reason for this: they want the lines to move fast. Editing the contents of a DataGrid control is practically impossible without the mouse. However, we've seen many similar applications that allow users to enter orders/invoices by editing a grid control. To better understand the requirements of such an application, consider how cashiers at large department stores work: most of the time they scan barcodes. They don't touch their keyboards, except to print the reciept. When the scanner fails to read, the cashier enters the barcode manually. If the barcode can't be read at all, they can search by a product code that's printed on the label.

The Application's Interface

Short of building a custom control or buying a third-party control, your best bet for building an invoicing application is to base it on a ListView control. The ListView is a non-editable grid; the editing of the data should take place on a few controls outside the grid, and the ListView control should be used for displaying the invoice's rows. The form shown in Figure 18.3 is our idea of a functional invoicing interface.

Team Fly