2.6 Visual FoxPro base classes

Visual FoxPro base classes

I didn't write this book to explain all the FoxPro base classes and their details. However, I would like to take the time to point out some details that are worth a second look.

NODEFAULT

Every FoxPro base class method is inherited from some internal class. Most of these methods have default behavior attached. For example, the default behavior of the KeyPress method makes sure the operating system recognizes that a key was pressed.

As I mentioned earlier, you can overwrite methods by adding code to the method in a subclass. If this were also true for original FoxPro behavior, it would be very hard to use FoxPro base classes, especially for beginners. Every time you added code without doing a DoDefault() it would possibly overwrite important default behavior and cause severe misbehavior. For this reason, you can't just overwrite default behavior.

However, there might be some reasons why you would like to overwrite the default FoxPro behavior. In this case, you can use the FoxPro keyword NODEFAULT.

When you add code to a method, the original behavior is always executed after all the added code. This is very handy because you can use NODEFAULT at any position in a method. You can even use it within IF statements. Suppose you want the user to be able to type only the characters "Y" and "N" in a special textbox. The following code attached to the textbox would accomplish that:

FUNCTION KeyPress
LPARAMETERS nKeyCode, nShiftAltCtrl
IF NOT (Chr(nKeyCode)="Y" OR Chr(nKeyCode)="N")
NODEFAULT
ENDIF
ENDFUNC

Custom classes

The base class Custom plays a special role in the set of base classes. It might be the most frequently used class, too. Custom is used for most things that are not part of the interface. Custom classes are used to create manager and service objects, behavioral objects, business logic and more.

At first sight, custom classes might look like they don't have a lot of functionality, but they do. Custom classes feature a rich set of properties and methods. They are fully functional containers that feature methods such as AddObject(). They can also be edited using the Visual Class Designer, even though they don't have a visual appearance.

This is one disadvantage of the Custom class, because it's not exactly lightweight. For this reason, many people use other base classes, such as Line or Relation, when they don't need the whole Custom functionality. Of course, these classes were never meant to take the place of Custom. The Line class has a visual appearance, but if it serves as a replacement for Custom, its Visible property never gets set to .T., so this is not an issue. After all, these classes seem to work just fine and they are not as resource-intensive as Custom. This is really important when you instantiate lots of classes, or when performance is a big issue.

When Custom is used as a container, it isn't done to create interface classes, because custom classes have no visual appearance. A custom class is used as a container when you want to compose behavioral objects. This is not as obvious as creating composite objects for the interface, but in big applications you'll find more behavioral composition containers than interface containers.

Control classes

Control classes are one of my personal favorites. They are very similar to the Visual FoxPro Container class, but they automatically set all the member objects protected. This means that you automatically create very clean composite classes without having to worry about protecting member objects. In fact, member objects can't even be made visible to the outside world. They can only be accessed through a special interface that talks to these objects.

Figure 2 shows how a Control class looks in the Class Designer.

Figure 2. A sample control class being assembled.

In this example I created a composite class I can use for all my data-entry forms that require entering a customer name. The user can either enter the name directly, or click the command button to bring up a picklist form.

The class is composed of a control class and three different member objects. You can see the object's structure in the Properties window. Note that all the member objects are visible in the Properties window and can be modified. Figure 3 shows how this class can be used in a form.

Figure 3. A sample control class used in a form.

Note that the property sheet for the form does not show the member objects of the control class just the objects on the form.



Advanced Object Oriented Programming with Visual FoxPro 6. 0
Advanced Object Oriented Programming with Visual FoxPro 6.0
ISBN: 0965509389
EAN: 2147483647
Year: 1998
Pages: 113
Authors: Markus Egger

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net