Designing and Creating the Tasmanian Trader Classes

Six class libraries were created for Tasmanian Traders. Most of the Visual FoxPro base classes were subclassed so that the basic "look and feel" of the application could be easily maintained across components. As much generic functionality as possible was included at the class level so that the classes could be easily maintained and reused.

In deciding what classes to create, as much consideration was given to maintenance and future projects as to the current project. The goal was to encapsulate as much generic functionality in classes as possible. As a result, the underlying classes contain a fair amount of built-in functionality and they are designed to be integrated, but it isn't easy for someone to open the project, look at the components, and understand how the application works. Because the components in Tasmanian Traders are integrated so closely, you can't just take one or two of them, add them to another project that is organized differently, and expect them to work. You can quickly and easily expand Tasmanian Traders, though, or other applications built around the same model, by subclassing the appropriate classes.

Instead of adding the AddNew, Save, Delete, Restore and table navigation methods to the form class, the developers could have created a custom class to hold table operation methods and added an object based on that class to form classes or directly to forms. This would provide more flexibility because the functionality could be added to any form (or even container or control classes) later in the development process, regardless of its parent class. On the other hand, this would provide an additional layer of reference whenever the methods were called and, if the custom class were contained in a different .vcx file, another file would have to be opened when the forms opened. Because the class structure was clearly delineated before the forms were created and all forms bound to data were to inherit from tsBaseForm, the methods were included in tsBaseForm.

In Tasmanian Traders, a toolbar provides user access to functionality that is common to all forms. An alternative would be to create a class of command buttons to provide this functionality and add an object based on the class to each form. The advantage of this would be that the user might more easily associate the buttons with the form, and a user could more easily access the command buttons with the keyboard. On the other hand, Microsoft Office standards call for toolbars, so users are familiar with them. More importantly, the toolbar didn't take up any additional space on the forms and didn't add any additional controls on forms that already had quite a few controls. Additionally, the toolbar can be customized more easily at run time based on the access level of the user.

The environment settings were saved in a class so they could be set and restored in a single operation. Another benefit of saving environment settings in a class and restoring them in the code associated with the Destroy event is the fact that it is easy to recover when crashes occur in testing. Issuing RELEASE ALL causes the object Destroy events to fire, restoring the original environment settings.

See Also

Solutions Samples | Tasmanian Traders Sample | Creating the Specification for Tasmanian Traders | Designing the Tastrade Database | Writing, Testing, and Debugging Tasmanian Traders | Tasmanian Traders Class Libraries