3.3 Visual vs. non-visual classes

Visual vs. non-visual classes

One of the great features of Visual FoxPro is its Visual Class Designer. It allows you to create classes in a visual way rather than deal with a huge amount of source code. However, you don't have to use the designer. You can always go the source code route; by doing so, you gain a couple of advantages.

Advantages of non-visual classes

Let's examine a couple of reasons for using source-code-only classes. First, they might be a bit faster. According to my own measurements, classes that are stored in PRGs instantiate about twice as fast as classes that are stored in VCX libraries. This changes from scenario to scenario, but it seems that source code classes are a lot faster, especially for first-time instantiation. Once an instance of a class has been created, FoxPro caches the class definition, and the speed seems to be about equal.

The reason for the speed disadvantages of visual classes is due to the way they are stored. VCX files are simply DBFs with a different extension. When a class gets instantiated, FoxPro scans the table, looks for compiled code that is stored in the table, and checks for information about possible parent classes. If parent classes are found, they have to be searched as well. Classes that are stored in PRG files are one huge chunk of compiled code, and VFP doesn't have to add all the overhead of SEEKing classes and their inheritance information.

Another factor that needs to be considered is class size. The larger the class, the less the difference in instantiation speed. The reason is simple. The bigger the class, the longer it takes to instantiate it. If it takes 50 milliseconds to instantiate a class, it doesn't really matter that it took three milliseconds to search the VCX and only one to find the definition in the PRG file. However, if it only takes a millisecond or two to instantiate the class, an additional overhead of three milliseconds matters a lot.

A couple of handling issues seem to be resolved a lot better in source code classes. Include files (.H extension files), for instance, are hard to handle in visual classes, and you're also limited to a single include file at a time. Further, you cannot use precompiler commands wrapped around methods or property definitions.

Another issue is size. Visual class libraries have a tendency to grow huge, because every time they are modified, FoxPro deletes the old version of your class and adds it again at the bottom of the file. Also, a table with memo fields is always a little bigger than a plain text file. Source code classes, on the other hand, are very compact. Furthermore, because source code classes are stored in regular text files, file corruption isn't a big issue. VCX files, on the other hand, are more fragile and might get corrupted every now and then.

The final advantage I want to point out is the ease of renaming classes, properties and methods, and the ease of redefining class structures. However, this advantage might also turn into a disadvantage because renaming and redefining can lead to other problems further down the road.

Why not go the visual route?

Going the visual route has many advantages. Almost all of them are a result of the proper internal organization of classes in each library. It's easy to browse source code on a per-class basis. Viewing class hierarchies and inheritance trees is supported by many tools like the Class Browser. Visual design tools consolidate properties and methods from classes and superclasses and display all the available ones in a properly ordered list called Property-Sheet.

Using non-visual classes, you're on your own with all these issues. Non-visual class libraries can be a big mess of code that has no particular order or organization whatsoever. Properties and methods are spread over the whole file, possibly even over multiple files, and there is no way to see them all at once. This makes it easy to forget about them, or even to redefine them accidentally, since there is no integrated mechanism to warn you about a possible problem. This gets even trickier if you want to use predefined events. In the property sheet, you can simply pick one of the available events and add code to it. In source code, this isn't so easy. You have to remember the event names for each class and where each class was derived from. Otherwise, you have to look it up, which is a very time-consuming process.

The Visual Class Designer takes care of all the stupid little standard tasks like adding objects to containers, setting properties, and adding code to methods. Following the concept of "information at your fingertips," the whole class definition is broken into pieces to show only the part of the class you're currently working on. This enhances productivity a great deal so you can concentrate on the essentials of programming, which is resolving a business problem not taking care of technical issues.

The majority of the visual design tools have been enhanced in Visual FoxPro 6.0. The Visual Class Designer got a whole new dialog to manage methods, properties and member objects, as shown in Figure 4.

Figure 4. The Visual Class Designer's new Edit Property/Method dialog
for managing methods, properties and member objects.

Using this dialog, you can create and delete new properties and methods, specify member visibility, and create access and assign methods. After using this dialog for a couple months, it was hard for me to imagine going back to Visual FoxPro 5.0 and living without it.

Another great tool that has been around since the first version of Visual FoxPro is the Class Browser. It has changed a lot since then; it's become easier to use and more powerful at the same time. The new browser also has a slightly different look and feel, as illustrated in Figure 5.

Figure 5. The new Class Browser.

The browser allows you to view classes in hierarchical or alphabetical order, even across class libraries. It also displays class details such as properties, methods and class documentation. We'll examine the Class Browser in more detail in Chapter 5.

Of course, all these tools are only in addition to the centerpiece, which is the Visual Class Designer itself. It consists of four main components: the Class window, the Code Snippet Editor, the Properties window and the Classes/Controls toolbar. See Figure 6.

I do not intend to explain the details of the Class Designer because many other people have spent a lot of time doing that already. I think the advantages of this visual design tool are rather obvious.

A further advantage of visual classes is the ability to create builders. Builders can automate tasks while designing a class. The concept of builders is unique to Visual FoxPro. It is based on the fact that FoxPro always uses live objects in the Visual Class Designer. This means that you can talk to classes programmatically, as if they were objects. This way you can assign properties, add code to methods, and instantiate new member objects. Despite the fact that this is an extremely interesting topic, I will leave this one to another book in this set.

Also, keep in mind that most third-party tools are optimized for visual class libraries. Even some tools Microsoft provides rely on VCX storage. A typical example would be the Modeling Wizards that I'll discuss in Section 3 of this book.

Visual classes: Nintendo for adults?

Here are some of the arguments I keep hearing: "Real programmers don't use visual design tools" and "The Visual Class Designer is like a video game for adults." To make a long story short: I couldn't agree less! (This is sort of like the old adage "Real programmers don't use code generators.")

Does a person become a better programmer because he's able to specify a default value for a property in source code rather than in a Properties window? I don't think so! Does one become a better programmer because he is able to identify a method in a huge PRG file rather than getting to it with a double-click in the Visual Class Designer? I don't think so! Does one become a better programmer because she can add member objects programmatically rather than dropping them in a container by a simple mouse operation? I doubt it! Does one create more efficient code when creating PRGs than when using VCXes? Well, maybe! But even if non-visual classes have a slight performance advantage, other issues outweigh that by far. Creating user interfaces in a non-visual way is quite a nightmare and the results are usually rather ugly. And even for non-interface classes, productivity and handling benefits are overwhelming.

Figure 6. The four main components of the Visual Class Designer.

In the end, the only difference between good and bad programmers is the resulting application they produce, and in order to create a good application, highly productive programmers are needed. At the same time, code quality has to remain high.

Visual design tools, property sheets, code snippet editors and the Class Browser are outstanding tools that raise a programmer's productivity and help to maintain code quality at the same time. Let's be more productive!

Some classes are non-visual only

Unfortunately, not all classes are available in the Visual Class Designer. Among the ones that can only be edited in source code are Pages (not PageFrames), Grid Columns and Headers. However, you can subclass all these classes in source code.

Many of the classes that can't be modified in a visual way are specialized containers that can only live in certain other containers. Pages, for instance, can only live in PageFrames, and Columns can only live in Grids. Nevertheless, almost any kind of object can be contained in these classes. Usually you'd modify the container classes in the Visual Class Designer and set some kind of property to instantiate these specialized member objects. In Grids, for instance, you can simply set the ColumnCount property and FoxPro will add new columns on the fly. However, all the added columns are of the FoxPro base class Column and can't be of a special user-defined class. If you want to add your own column class, you can define that in source code, set the ColumnCount property to 0 and add the columns on the fly (at runtime) using the AddObject() method. Because columns have to have some member objects, these must also be instantiated on the fly or defined in the source code. No matter how this is done, you always lose the advantages and power of the visual design tools.



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