Mike Pope
Microsoft Corporation
July 1999
Summary: Discusses the Web application tools in Microsoft® Visual Basic® version 6.0 and discusses when to use them when creating Web applications. (14 printed pages) Includes:
Introduction
Web Applications: Some Background
Reach vs. Rich, Thin vs. Thick
Client vs. Server Processing
Deciding on Where to Put the Processing
Microsoft Web Technologies
Creating Web Applications in Visual Basic
Summary of Visual Basic Web Technologies
Creating Server Applications in Visual Basic
Embedding Web Functionality into Visual Basic Forms
Hosting Visual Basic Applications in a Browser
Final Thoughts
If you're not already creating Web-based applications, you might soon be. Applications that until recently would have been created as standard Microsoft® Visual Basic®-based applications—forms plus processing plus perhaps database access—are increasingly being developed to run over a corporate intranet or across the Internet. There can be numerous benefits, among them easier deployment, easier maintenance, scalability, and lower total cost of ownership (TCO).
Even if you don't foresee a Web application in your near future, you'll want to know what you can do in the Visual Basic development system on the inevitable day when your boss or customer asks, "Can we put this application on the Web?"
Fortunately, along with a bunch of other cool stuff, Visual Basic version 6.0 includes a host of tools that help you create Web applications. In fact, it's an embarrassment of richness, and if you're new to either Visual Basic 6.0 or to Web development, it can seem a little overwhelming at first. Which to use? When?
In this article we'll sort out for you what the Visual Basic Web application tools are and when you would use them (or not, which might be just as important). Incidentally, we won't be documenting the tools in detail—we'll leave that job for the documentation included with Visual Basic 6.0. By the time you finish this article, though, you should have a clear idea of where to turn in the doc set.
Before we give you details about what the Visual Basic Web application tools are for, it might be wise to set the stage a bit. If you're an old hand at Web development on Microsoft platforms, you probably won't need this review. If you haven't sorted out Web development yet, read on.
As you might know, Microsoft believes in a complete, formal architecture for building Windows®-based Web applications that goes by the name "Microsoft Windows Distributed interNet Applications Architecture"—Windows DNA for short. There's a great description of this architecture on the company Web site at http://www.microsoft.com/dna/, including an awesome 3.0D animated model at http://www.microsoft.com/dna/images/dna.html.
What we'll do in this article is focus specifically on Visual Basic and its Web application tools. You will then be able to see clearly how Visual Basic and your programming skills fit into this larger Windows DNA picture.
To begin with, Web applications are by definition client/server applications, consisting of the browser (the client) and a Web server. The simplest Web application is "static"—browsers request pages and display them. There is no processing other than the Web server serving the page and the Web browser rendering the text.
Things get more interesting when you want to add some processing to the application. What kinds? Validating user input. Changing the Web page in response to a user's input. Performing business logic. Looking things up or storing them in a database. Controlling what pages users can see. In other words, all the types of processing that you'd do in a stand-alone application.
Unlike traditional Visual Basic-based applications, the client side of a Web application is usually a browser that can have an unknown set of features and capabilities. If you are creating an application for a public Web site, for example, people can use all sorts of browsers to access it. Some of these browsers might have limited capability to perform the types of processing just mentioned.
Others can perform very sophisticated processing. A good example of the latter, of course, is Microsoft Internet Explorer (version 4.0 or later), which supports the wide-ranging capabilities of dynamic HTML (DHTML). Of course, the richest client of all is a standard Visual Basic form. Using Visual Basic, you can create a Web application that doesn't even require a browser at all—instead, it uses a Visual Basic form that includes browsing capabilities or other Web technologies.
The differences in client capabilities will be one of the major factors in deciding how to design your application. Does your application have to be accessible by many different browsers, or will you know in advance that all users will have Internet Explorer 4.0 or later? Can it consist of Visual Basic forms? This difference in client capabilities is sometimes referred to using the shorthand terms reach and rich.
A reach application is one that can reach (get it?) the widest audience. In Web terms, this typically means an application that's accessible to any browser. Consider a Web application such as Hotmail™, which you can access from pretty much any type of browser on any type of computer. That's a lot of reach. In contrast, a rich application provides a richer user experience (of course), which generally means a fancier user interface and faster response to user actions.
Reach versus rich is not a black-and-white distinction, it's a matter of degree. The following graph gives you an idea of the range for both.
Figure 1. Reach vs. rich application
A related but different distinction is also made between a "thin" and a "thick" client. A thin client is small and lightweight but by definition is not very rich. Think browser. A thick client bundles lots of functionality into the client, making it very capable but giving it a bigger footprint. A typical Visual Basic-based application, which requires forms, code, and the Visual Basic run time, would qualify as thick under this definition.
What all this reach and rich stuff really means is "Where is the processing done?" Reach applications rely on the server to do the processing in order to support a variety of browsers as the client. Rich client-based applications can rely on the front end to do a lot of the work.
As an example, imagine an application that displays a list of employees in your company, five to a page. The user clicks a Next button to see more names. In a reach application, you assume the client isn't very capable, so you put the "next page" processing on the server. The Next button packages up information such as the current page number and sends it to the server. The server refreshes the query based on the current page number, composes a new page with the next five employee names, and sends it back to the browser. The process of getting the next page involves a round trip to the server. This type of application can be run by any browser, but because of the round trip to the server, response time can be slow.
Figure 2. Server processing in reach applications
In a rich application, on the other hand, the Web page comes from the Web server, but the client handles the data itself. When the query is first generated, all the relevant data (the entire recordset) is made available to the client. Thereafter, when the user clicks Next, client-side processing handles all the paging logic itself. The result is typically much faster response time.
Figure 3.0. Client processing in rich applications
A primary criterion for selecting client or server processing, therefore, is how capable the client is: If you are creating a reach application, it will be server-based. Publicly accessible Internet Web sites are usually reach applications, because you want as many people as possible using the application (with whatever browser they have).
On the other hand, suppose you are writing an intranet application for a corporation that has standardized on Internet Explorer. Do you automatically decide to design a rich-client application? Although your first instinct might be to say "of course!" the answer actually is "It depends."
In addition to the simple choice presented by what the client will be, you have to consider these additional factors:
One final factor has to do with network topology. If you are working on an intranet application, you can probably count on direct access between a client computer and other networked computers—for example, a direct link between the client and the database. In an Internet application, the communications protocol is usually HTTP, which normally does not allow access to databases scattered around your network. For a reach application, database access will usually have to be done from the server, not the client.
Note If the client and server are properly configured, the application can use Microsoft Remote Data Service (RDS) to communicate directly from client to database. For more information, see http://www.microsoft.com/data/ado/rds/.
Microsoft provides a number of choices for creating both client-based and server-based Web applications. For rich, client-based applications, the following are available:
Conversely, for wide-reach, server-based applications, Microsoft provides Active Server Pages (ASP), which is a technology supported by Microsoft Internet Information Services (IIS). ASP combines HTML text with code (generally script). The script is executed on the server when the page is requested.
The following graph might help you to understand where these different technologies fit together.
Figure 4.0. Available Web technologies for client- and server-based applications
Now let's move on to what you can do in Visual Basic.
As noted at the beginning of this article, Visual Basic 6.0 offers a number of technologies for creating Web applications. You might extend an existing Visual Basic application by adding some Web access. Or you might create a new application tailored specifically to the Web.
In all cases, there are several reasons to use Visual Basic as the development tool for your Web applications:
Let's review the available Web technologies you can use in or create with Visual Basic:
The following table sorts out these options and provides information about which technology is rich or reach, what sort of client you can use, and where in this article we provide more details. Be sure that you read the details about each technology, though, because each technology has specific factors that you'll want to take into account when designing your application.
Table 1. Visual Basic Web Technologies
| Rich or reach? | To do this | With this as client | Use this VB technology | See this section |
| Reach | Create server applications. | Any browser | WebClasses ("IIS applications") | "Creating Server Applications in Visual Basic" |
| Rich | Extend an existing application with some Web access. | Visual Basic forms | Visual Basic forms + Internet controls | "Embedding Web Functionality into Visual Basic Forms" |
| Rich | Create Visual Basic applications that use a browser as the container for the form. | Visual Basic forms running in Internet Explorer 3.0 or later | Active documents | "Hosting Visual Basic Applications in a Browser" |
| Rich | Use Visual Basic to create and manipulate DHTML Web pages. | Internet Explorer 4.0 or later | DHTML applications | "Hosting Visual Basic Applications in a Browser" |
We can now update the graph presented earlier to show you how all these technologies are related to one another. Conveniently, there's a Visual Basic Web technology for each stop on the reach-versus-rich curve.
Figure 5. How the Visual Basic Web technologies relate
If you want to create a reach application, the processing for it has to be on the server. In Visual Basic, the solution is WebClasses.
Let's start with a brief overview of how IIS handles server-side processing. IIS supports a special type of Web page called an Active Server Page (ASP). An ASP page is an HTML page that also contains hooks for server-side processing.
When IIS sees the .asp extension on the file, it first performs all the server-side processing specified on the page. (ASP pages often have server-side processing written in script.) This server processing can consist of whatever business logic you need in your reach application. If the server process needs to send output to the user, it modifies the HTML text on the page. When the server processing is complete, the page is sent to the browser, complete with all the HTML modifications made by the ASP processor.
Figure 6. IIS server-side processing
Note that the server does all the processing. By the time the page gets to the user's browser, all the processing has been done, and the user has no idea that some of the page content might have been generated dynamically by the server. Plus, of course, the user's browser doesn't have to do a thing except display the HTML on the page.
In Visual Basic, you can build this type of server-side processing using a technology called "IIS Applications," or "WebClasses" for short. WebClasses allow you to build the server logic in Visual Basic and then link it to ASP pages. When the browser requests the ASP page, the ASP page in turn calls your WebClass to perform the server processing. Figure 7 provides a simplified version of how WebClasses work.
Figure 7. Server-side processing using WebClasses
WebClasses can generate not only output, but can take input as well. For example, you might create a Web page that contains a data entry form. The user fills it in and clicks a Submit button (as they're called in Web parlance), which sends the completed form to a specific ASP page on the server. The ASP page calls your WebClass, which can then pick out the values of the individual controls on the form and carry on. It's likely you'll also respond to the user by sending another page acknowledging the entry, displaying an error message, or whatever is called for.
An important point to remember: This simple data entry form involves a round trip to the server. In fact, in a purely server-based application, any time you need to run code, a form has to be sent to the server. Do you need to check whether the user entered a number correctly? Submit the form (page) to the server, call a WebClass on the server to validate it, and then return the form to the user. That is, unfortunately, the price of a true reach application.
For most Visual Basic-based Web applications, WebClasses are the way to go. Here's a sampling of reasons:
You can read a lot about WebClasses in the Visual Basic 6.0 documentation. (If you need more convincing about WebClasses, see the topic "Advantages of IIS Applications" in the documentation.) There are additional articles about WebClasses, both in the Visual Studio® edition of MSDN as well as on MSDN Online. Try the article called "The WebClass Developer's Primer" available in the Technical Articles\Visual Tools section of the MSDN Library.
Finally, there is also a sample site written using WebClasses that has lots of examples and source code you can download. Check it out at http://vblive.rte.microsoft.com/. (You have to register, but it's free.)
Perhaps you are at the opposite end of the spectrum: You have a standard, form-based Visual Basic application (a classic rich application), and just want to add a bit of Web functionality to it. You can extend an application to include Web functionality by embedding Web-oriented controls. For example, you can add a control to a form that allows the form to act much like Internet Explorer, with the difference that you have complete control over display and navigation.
There are a variety of Web-oriented controls available, including:
In general, you don't want to use these controls to create a full-fledged Web application. (For that, you really want to be using a true browser as the client.) Instead, these controls are useful for adding some Web functionality to an application that otherwise is primarily client-based.
The WebBrowser control acts as browser window, rendering HTML (and DHTML) the way Internet Explorer does. You can add buttons, text boxes, and other standard Visual Basic controls to provide navigation and other browser functionality. This control is part of Internet Explorer.
The DHTML Editing control goes one step further: It not only renders a document, but also provides WYSIWYG editing. Using this control, you can provide users with a complete HTML editing environment. In fact, one of the example applications provided with the DHTML Editing Component is an HTML editor written as a Visual Basic application.
Another useful control, the Internet Transfer control, performs low-level transfer of text, images, and binary information using the HTTP protocol (to download) or FTP protocol (to upload or download). The control doesn't render any information in a window, it simply takes care of the communication between one point and another on the Web. A good example application for the Internet Transfer control would be the Web Publishing Wizard. This control is part of Visual Basic, and you can read about it in the documentation.
A third way to create Web applications in Visual Basic is to create a hybrid between Visual Basic forms and Internet Explorer. There are two alternatives:
An active document is a form that can be hosted in another container; here, the container is Internet Explorer. You might recognize this technology, because it's also used at times by Windows Explorer, Microsoft Word, and other applications running inside Internet Explorer. Active documents were introduced in a previous version of Visual Basic and are compatible with Internet Explorer 3.0.
You can create an active document application the same way as any other Visual Basic application—you place Visual Basic or ActiveX controls on a form (called a UserDocument designer in this context), write code behind the controls, and compile the project. The only difference between an active document and a normal Visual Basic form is that the active document then runs within the Web browser.
Active documents mix stand-alone Visual Basic applications with true browser-based applications. As a consequence, an active document is probably a niche technology that has short-term benefits (discussed next) but that you probably would not want to plan on using extensively or long-term.
Active documents are not stand-alone applications. When you deploy an application that includes active documents, you must include the Visual Basic run-time dynamic-link library (DLL) as well as the .vbd file and any other files associated with the program. And naturally, the user has to have a browser that will host an active document. For practical purposes, that means Internet Explorer 3.0, or for better performance, Internet Explorer 4.0 or later.
The second way to host Visual Basic-based applications in the browser is to use DHTML applications. This technology, first introduced in Visual Basic 6.0, is somewhat like active documents, in that it's used to create Visual Basic applications that are hosted in a Web browser. However, a DHTML application is a true DHTML Web page, not just a form hosted in the browser.
DHTML applications are created using a tool called the DHTML Page Designer and can use a combination of the DHTML object model and HTML rather than simply Visual Basic. DHTML applications can include either ActiveX controls or special versions of the Visual Basic controls designed to work with DHTML pages.
Note There are some limitations on which ActiveX controls work with the DHTML Page Designer. See the Visual Basic Readme file for details.
As with active documents, DHTML applications are not stand-alone applications—they, too, are thick. When you deploy a DHTML application, you must include the Visual Basic run-time DLL, as well as the .dsr and .dsx files and any HTML pages or other files associated with the program. Also, the application must be used in a container that supports DHTML, such as a Web browser (or a Web browser control). Again, this probably means Internet Explorer 4.0 or later.
Both active documents and DHTML applications provide some of the same advantages:
In addition, active documents provide specific benefits. You might use them if:
On the other hand, DHTML applications have the advantage that they put the full power of DHTML at your disposal, which gives you control over the UI displayed in the browser.
Both technologies are useful for the reasons just listed, but there are some offsetting factors that you should keep in mind, too. For starters, both technologies require users to have the Visual Basic run time and Internet Explorer as a browser (host).
Some other factors to consider for active documents are:
A general rule for active documents is this: They can be useful for migrating specific, focused parts of an application to the Web. Don't create your whole Web application with them, and plan on converting your active documents to true browser-based applications in a future release of your application.
DHTML applications also have some specific downsides:
For more information about active documents, see "ActiveX Document Advantages," "Building ActiveX Documents," and "Creating an ActiveX Document" in the Visual Basic Component Tools Guide, available in the MSDN Library. For more complete information about DHTML applications, see "Developing DHTML Applications" in the Visual Basic Component Tools Guide.
At this point, you should have an idea of how and why and where you can use Visual Basic for Web applications. As with any type of application, the first thing you must do is examine your goals and your audience. In this case, you're choosing between "reach" (server) and "rich" (client) applications, based not just on what front-end users will have, but on additional factors such as security and processing load.
Then you have the interesting job of deciding which Visual Basic technology (or technologies!) to use when creating applications. The all-around best bet is WebClasses, which will give you the most bang for the your development buck. The other Visual Basic Web technologies address more specific application, customer, and development needs.
Of course, we've only scratched the surface here. You can find much more detail about each of these technologies in the Visual Basic documentation. Another wonderful source of information is MSDN Online, which is packed with documentation, articles, and tips about Web design.