Visual Basic 5.0 vs. Delphi 3.0

We take a new tack in our product reviews by comparing how well the latest versions of the two most popular development environments create ActiveX controls.

Product Summary

Finding ways to make application development more efficient and to involve business domain experts more directly in the development process has long been a goal of the software industry. Few question the need for the kind of programmer who can put the pedal to the metal and code tight loops and high-performance text manipulations. But most observers also feel there must be a way to push those who are skilled in business processes right into the line of fire as well. With the rise of object-oriented programming in the late 1980s, the concept of dividing these tasks between component creators and component assemblers first began to make the rounds of guru-driven keynote speeches.

But the languages that targeted this division of labor, such as Smalltalk, Objective C, and even C++, still required too much skill on the part of the assemblers. The assemblers' main skill was supposed to be business knowledge, but the environments required a high level of programming skill. C++, with the confusing rules of pointers, curly braces, and even semicolon placement, was particularly unsuited to the task. Microsoft, among others, recognized this plain fact and began to push Visual Basic, successfully, as a language for component assemblers. But the need for new components continued to outstrip the supply of programmers skilled enough to handle the chore. So Microsoft with Visual Basic, and later Borland with Delphi, decided to enhance these higher-level programming environments so they too were practical choices for creating components.

In their latest incarnations, Visual Basic 5.0 and Delphi 3.0 are capable of creating components in the form of ActiveX controls. You can use these controls in almost any programmable or scriptable 32-bit Windows tool. For example, you can use a Visual Basic-created control in a Delphi application and vice versa. You can also create office productivity applications (word processing, spreadsheets, and graphics), and even web pages by using VBScript or JavaScript as the controlling language.

In this article, we'll take a new tack for Software Development product reviews, called the SD Tech Test. A Tech Test will pit two or more competing products against each other by comparing their ability to handle a specific task. This inaugural test will compare the abilities of the latest versions of Visual Basic and Delphi to create ActiveX controls. Not wanting to stray too far from the norm, we'll start by highlighting the significant product changes that come with the new releases. Following that, the article will cover the construction of an ActiveX control in both Visual Basic and Delphi.

What's New for 1997?

The most obvious change to Visual Basic in 5.0 is the new, Developer Studio-like MDI. No longer must developers suffer with the scattered, hard-to-control sub-windows that were always getting lost on the desktop in Visual Basic 3.0 and 4.0. The IDE is largely shared with two cousin versions-Visual Basic Control Creation Edition (available for free download from Microsoft's web site) and Visual Basic for Applications (shipped with Office97 as well as with applications from more than 40 other vendors who licensed it from Microsoft)-and was discussed in depth in part one of the Microsoft Office97 Developer's Edition review (April 1997).

Significant changes to Visual Basic 5.0 include Microsoft Repository 1.0, a long-demanded native code compiler; and a complete retooling of the IDE via design-time controls into an open, extensible platform (as compared to the hard-to-handle, add-in architecture of Visual Basic 4.0). Included in the Enterprise Edition is Remote Data Objects 2.0; Visual SourceSafe version control; and developer versions of SQL Server 6.5 and Microsoft Transaction Server. The execution engine has performance improvements up to 2,000% over Visual Basic 4.0.

Delphi 3.0 provides ActiveX support by extending Object Pascal with object interfaces as a native part of the language. This means that any object built with Delphi that supports one or more interfaces is automatically an ActiveX COM object. This support also includes web-enabled applications through ActiveForms, which makes an ActiveX control and a host HTML page for any Delphi form. Unlike Visual Basic, Delphi has always supported true inheritance, and this version adds visual inheritance. Organizations can develop form templates and use them across projects; should corporate communications change the official company colors, you can update all applications by updating the base template. Delphi 3.0 also includes an object repository. However, while useful, it is nothing like the complex, database-hosted Microsoft Repository. As the online help says, the repository is a structured text file that contains references to forms, projects, and experts.

Both products add a new level of sophistication to the source code editor through features (which differ slightly between the products) like code completion (syntax assistance) and parameter tips (which pop up like ToolTips). Both also come packaged with a larger set of base controls, a sophisticated RDBMS (SQL Server and InterBase), and a ToolTip evaluation expression-hold the cursor over an expression at run time and a ToolTip is displayed with the current value.

Let's Build a Control

The central concept behind ActiveX is sharing functionality among different applications. For this article, I built a control that combines a few labels, a list view, a popup menu, a text box, a drive combobox, and a directory list into a simple file list viewer. There's not much extra functionality except that you can sort the files in ascending or descending order by name, size, or date. The control was designed to illustrate possibilities, not as a complete implementation. To paraphrase Kernighan and Ritchie, a polished implementation is left as an exercise for the reader. Figure 1, shown on page 63, features the control in run mode.

An ActiveX control created with Visual Basic is always composed of a UserControl object, plus any controls that are added to the UserControl. In a sense, a UserControl is a special type of form. The process of building the control differs little from creating the same form as if it were simply a single form in a standard project. The biggest difference (for both Visual Basic and Delphi) is that you can't just press F5 and go into run mode to test your work. Instead, you must create a host project and add an instance of the control to a form. However, with the addition in this version of project groups and the ability to have multiple projects open concurrently, Visual Basic does make the test portion a shade easier to manage.

After the control is complete, you can use the ActiveX Control Interface and Property Page wizards to build the public interface and design time property pages for the control. While both of these wizards are understandable, they're not as simple as I expected. For example, the ActiveX Control Interface wizard helps you map the properties, methods, and events that you are exposing to users of your control to the actual properties, methods, and events of your control's constituent controls. However, I wanted to map the Font (and FontSize) property of the three labels to a single exposed property, but the wizard insists on one-to-one mapping. I had to go into the generated Property Let method and add the code myself.

I expected the Property Page wizard to use the knowledge of standard property types and to use an appropriate control. Instead, it adds a label and text box for each property. For example, when I exposed the Font and FontSize properties, I wondered why the wizard didn't add a button to launch the standard Font dialog. I exposed the BorderStyle as well, which only has two valid values. In the standard control properties window, BorderStyle is a combobox, but the wizard generated a text box, and the corrections were left to me. You'd think the wizard could at least let you choose the user interface widget to use for each property and offer access to standard dialogs.

Delphi offers two options for building these controls: an actual ActiveX control or an ActiveForm. In Borland parlance, what Microsoft terms ActiveX controls created by Visual Basic are actually ActiveForms. You must create Visual Basic ActiveX controls within a form container by dropping pre-existing controls on the surface. To distribute these controls, you must also send a 1.5MB run-time interpreter DLL unless you know that the run time is already there because either it was sent with an earlier project or the user has Microsoft Office97 installed (the Office97 Visual Basic for Applications uses the same run time).

Delphi-built ActiveX controls require no large run-time interpreter, and they run faster because they're compiled to machine code. While Visual Basic lets you extend existing controls by hooking into their existing properties, methods, and events, and adding their own public interface, Delphi adds true inheritance on both the code and visual levels. On the other hand, Delphi doesn't provide support for creating property pages. In Visual Basic, in addition to the wizard, a Property Bag object is supplied to read and write an arbitrary set of properties across invocations of an object. While it would be a bit of work, there's no reason a company that selects Delphi for control authoring couldn't create its own Property Page expert.

This being the age of the Internet, both tools include a generous helping of web-related material. Delphi includes a bevy of server-side pieces such as a web server application type as well as classes that manage HTTP, CGI, ISAPI, and HTML. Visual Basic supplies a substantial set of client-side components such as an ActiveX browser control; the Enterprise Edition adds Microsoft Transaction Server, which handles management of server components written in any compatible environment (such as, say, Delphi).

Choosing between these two tools requires that you understand which factors are important for your project. Are the controls intended for a controlled group (for example, a corporate intranet vs. the Internet)? Are Visual Basic applications already in use by the target audience, so the run-time DLL is already installed? Is a corporate style standard in place, but one that changes with relative frequency, so Delphi's visual inheritance becomes an important factor? Is run-time performance the main consideration?

Both products have their advantages and disadvantages, and I found it difficult to decide between them. I should disclose my background so you can judge my biases, however. I worked for two years as a Visual Basic programmer; on the other hand, I've been acquainted with and developed in Delphi since the 1.0 beta. To me, Visual Basic is easier to work with. It provides more resources, both in terms of tools and documentation. The performance is acceptable for situations I've been involved with, and that means that I would choose Visual Basic. But Delphi's Object Pascal implementation enables true object-orientation and form inheritance. It means you can subclass and extend all the controls in Delphi in a straightforward way. Finally, the performance difference that comes from Delphi's native code compiler leaves Visual Basic 5.0 way behind.

I think I've been fairly clear about which choice my own bias leads me to make, but to accurately score the results of this inaugural Tech Test, you need to weigh the relative importance of the different factors and find your own answer.

Bill Lazar is a contributing editor to Software Development. He also develops Internet information resources at NetDynamics Inc. You can reach him through Software Development magazine.