Mega Code Archive

 

Categories / Delphi / Forms

 

ActiveForms design and deployment

Title: ActiveForms - design and deployment Question: You can be forgiven if Microsoft`s OLE system and its marketing confuses you. It seems to confuse many. It has gone through numerous incarnations and name changes over the last few years as Microsoft tries to position itself in various markets. In its most recent incarnation, ActiveX, it is being positioned as an Internet control tool, able to execute code across the Internet. As such, it is a competitor for Java, and Microsoft seems quite adamant about promoting the technology as a solution for web based applications. You can use Delphi to build powerful, full-featured ActiveForm based applications. Delphi provides the wizards, classes, and interfaces that make building ActiveForms a very straight-forward process. In Delphi, an ActiveForm is an ActiveX control that encapsulates a Delphi form. Since ActiveForms are really ActiveX controls, they can be used in any application that supports ActiveX. Furthermore, you can put any type of component on an ActiveForm--you are not restricted to using only ActiveX Controls on ActiveForms. As a result, it is quite possible to encapsulate an entire application in an ActiveForm. However, there are a number of problems with ActiveX and ActiveForms that should at least give a software developer pause before delving into the world of ActiveX. None of the problems are showstoppers, but there are issues that need to be considered before one goes off and deploys a host of ActiveX controls on a commercial website. Answer: This is an article from Nick Hodges ! You can find it also on http://www.icss.net/~nhodges/DL320.htm Security Issues Threat The biggest concern with ActiveX and its use is, of course, security. In early 1997, there were a number of holes discovered in ActiveX technology. It shouldn't be any surprise, really. An ActiveX control or an ActiveForm is nothing more than an OCX that resides on your machine and executes code. The browser runs the control, giving the illusion that it is being run across the net. But in fact, what actually is happening is that the control is downloaded to your machine from the server's site, it is registered on your machine, and then the code executes on your computer just like any other process. This, of course, means that an ActiveX control has access to your machine, just like any other process. There's really nothing stopping an ActiveX control from formatting your hard drive, for example. Microsoft's response to these security troubles have been part defiant and part conciliatory. They were, of course, quick to post a 'fix' to Internet Explorer 3.0 when the revelation of security problems was made. (Updates to the Internet Explorer and its comments on Internet security can be found at http://www.microsoft.com/ie/security/update.htm) Though no one has yet created an ActiveX 'virus' (as far as we know!), the potential is certainly there, and many users are rightly cautious and hesitant to accept an ActiveX control onto their machine, particularly from an unknown source. In addition, however, Microsoft argues that you should always practice 'safe surfing' and never download controls from unknown or untrustworthy sources. That is all well and good, but the casual or naive user may not be savvy enough to even know that there is any threat at all. Internet Explorer does afford a certain amount of security. You can set three different security levels on the browser. High security won't allow any ActiveX controls to be downloaded at all. Medium Security asks for permission to download any ActiveX controls, and Low Security provides no defense whatsoever, allowing any and all ActiveX controls onto the site. ActiveX controls themselves can provide a certain level of security. As we'll see a little later, a control can be signed by the developer as being safe and verified by the author. This adds a modicum of security, as one would tend to trust controls produced and verified by companies like Borland or Microsoft. However, this method offers little assurance when visiting the homepage of a college student. Certificates can be obtained from http://www.versign.com Recommended Uses Borland made a purposeful decision when they integrated ActiveForms into the IDE. The Web Deployment options make it clear that they intended ActiveForms for use within an Intranet or behind password protected sites. For instance, there currently is no facility inside Delphi for the deployment of an active form to a remote site such as your ISP. Because of their security limitations, ActiveForms require a certain amount of trust. (Indeed, trust is really the foundation of Microsoft's security plan). As a result, ActiveX tools are best used only in trusted environments such as Intranets or behind password protected sites where your customers might use them. You are not likely to provide your customer with dangerous or harmful ActiveForms, and there is a general sense of trust between a client and a contractor or between an employer and an employee. Where you don't want to depend on ActiveForms is on the open Internet. Actually, you could depend on ActiveX's if you want, but you can't really expect others to. Unless the security model for ActiveX improves -- or more importantly, user perception of the relative security of ActiveX improves -- many users will not want to accept ActiveX controls, even if they are code-signed by a seemingly trusted agent. Users can even set 'High' security, the default setting, in the Internet Explorer, and the browser will simply refuse to load any ActiveX control at all. If you have a site that is accessible to the general public, it shouldn't require an ActiveX control for it to function properly. You can shut out a lot of visitors -- and presumably potential customers -- if you insist on using ActiveX controls. Therefore, ActiveForms will work best on a client that has personal knowledge and trust in the provider of the ActiveForm such as an intranet administrator or a paid consultant interested in not being sued. If you are a consultant being paid to build an extranet web site for a client, or you are in an IS shop and tasked with building an Intranet for your company, you are probably a good candidate for building and deploying ActiveX controls and ActiveForms. If you are an entrepreneur trying to sell bicycle parts over the net and your company is named "Computer Hacker Bikes," most people will probably not be too excited about downloading and executing the cool ActiveForm-based website that you've placed out on the web Building ActiveForms Overview It should come as no surprise that Delphi makes building ActiveForms as easy as regular forms. As a matter of fact, there is really no difference between designing an ActiveForm and a regular form. You can use the Form Designer to add components and event handlers just like a regular TForm descendent. Adding properties is a bit different, but still doable. By using the IDE's Wizard to create an ActiveForm template, Delphi will do all the work for you of creating the code needed to compile your project into an ActiveForm. An ActiveForm is really nothing more than a glorified ActiveX control. Delphi creates ActiveX controls from any VCL-based component that descends from TWinControl, that is, components that have a Windows handle. Since TForm is such a component, it qualifies as one that can be made into an ActiveX control. A bit harder In addition to the security concerns above, there are some issues to deal with in building and deploying ActiveForms. The first is that it is a rather delicate process. A number of things have to happen in just the right manner, and if there is a minor typo in an HTML file or an accompanying file is not properly located, the ActiveForm will fail to work properly. Processing code across a network from the server requires using Microsoft's Distributed Common Object Model (DCOM) or Borland's OLEnterprise. Adding database capabilities to an ActiveForm requires a whole new way of getting at data that resides on a remote server. All of these facts add up to an environment that is a bit more complicated than distributing an EXE and a help file. If each component in the process is not properly configured, then the system will break down. However, when properly configured, you can take advantage of the multi-tiered architecture Delphi provides and build powerful, robust database applications that can be deployed across virtually any network, including the Internet. Furthermore, the only tool that can easily and relatively reliably display an ActiveForm is Microsoft Internet Explorer (Be sure that you have version 3.02, the most current version available at the time of this writing). Even with the most recent version, MSIE has proven to be a bit finicky about caching OCX's, and you generally have to close down and restart MSIE each time you want to display an updated version of your ActiveForm. (Note that you can use MSIE to debug your ActiveForm inside of Delphi). Third, you need to have a different way of thinking when building ActiveForms. Your ActiveForm is more than likely going to be sent out over the network to be automatically deployed on anther user's machine. As we will see, Delphi does a really nice job of making this easy. But what that means is that you cannot make any assumptions about the user's setup. Hard-coded pathnames, BDE Aliases, and other server side specifics may or may not be germane. Up until now, most web application development has been on the server side. ActiveForm programs run entirely on the client side of a network connection, and as will be shown, requires a shift in design, and a new way of attacking old problems. ...yet quite simple Despite the above comments, making an ActiveForm is simplicity itself. Simply select File|New and then select the ActiveX tab in the resulting dialog box. Delphi will then create a project that contains all the code for an empty ActiveForm. Once the wizard is done creating the project, you will see a very familiar site -- a form in the Form Designer, ready to accept components. At this point, there is not a lot of difference in the way that an ActiveForm and a regular form are designed and built. You can add any of Delphi's standard VCL components to your form, and they will behave just as you expect. You can use the form designer to create event handlers for those controls, and Delphi dutifully creates the code templates. The difference, of course, is that you are creating a library, not a program, and your form uses interfaces to allow access to the resulting OCX. An ActiveForm is made up of two elements, a descendant of TActiveForm, and the interface IActiveFormX. TActiveForm, which is declared in AXCTRLS.PAS, provides the standard Delphi class structure from TForm as well as the functionality needed for the form to act as an ActiveX (which it really is). IActiveFormX is an interface that is defined in the project's type library. This interface is what defines all of the methods and event handlers for the ActiveForm so that it can be accessed by MSIE and other tools that use ActiveForms. You can view the resulting type library by selecting View|Type Library, which will bring up the Type Library Editor. This paper is not meant to deal with all the capabilities of the Type Library editor, but it is interesting to see that this tool is used to add methods and events to the form itself. For instance, bring up the Type Library editor and select the IActiveFormX item in the TreeView on the left. Then press the Property button in the toolbar, and add a property called Tag. Hit the refresh button, and then take a look at the type library file that is created in the code editor. (You may have to use the Project Manager to bring up the *_TLB.PAS file created as part of the default project). Search through the file, and you can see that the Get_Tag and Set_Tag methods have been added to the IActiveFormX interface declaration, and they, of course, will let you change the Tag property value of your ActiveForm. You can do the same thing for events by adding OnXXX events to the IActiveFormXEvents dispatch interface. Example A simple example will illustrate a number of these points. Create a new ActiveForm in the IDE. The ActiveForm Wizard opens and presents you with the options for the ActiveForm. For this example, accept the default names for the ActiveForm name and implementation unit. Below these edit boxes, there are three control options that you can set -- Include Design-Time License - Selecting this option will cause Delphi to create a *.LIC file for your ActiveForm. If you create a design-time license for your ActiveForm, you can distribute your ActiveForm to other developers who can then use it in their design tools. Without this license, developers cannot extend or enhance your ActiveForm in another development tool. It might be interesting to note that once you place an ActiveForm on the Internet, anyone can download the control and use it on their own web pages. So if you use any sort of ActiveX control, be prepared to see it on other users web pages. They don't even have to load the file to their own machine, as they can reference your page directly. There are probably legal implications in doing this, but do note that it can be done. Include Version Information - Selecting this option will cause Delphi to include versioning information in the OCX. This information is stored in the VERSIONINFO resource type Include About Box - This option will cause the wizard to add a simple About box to the project. It also creates a procedure titled AboutBox that you can call to display the dialog. For this example, select the VersionInfo and About Box Options and click 'Ok'. Once the ActiveForm is created, you can add controls from the component palette as you would expect. Try adding a TAnimate component and a TButton. Set the TAnimate.CommonAVI property to aviFindFolder, and add the following code to the OnClick of the TButton: procedure TActiveFormX1.Button1Click(Sender: TObject); begin Animate1.Active := not Animate1.Active; end; Then, add a TGraphicControl such as TImage and add a Bitmap to the Picture property. And just for fun, add a TMemo, and in the OnCreate event for the form itself add procedure TMyFormX.FormCreate(Sender: TObject); begin Memo1.Lines.LoadFromFile('C:\autoexec.bat'); end; This last little technique shows you how easy it would be to manipulate your AUTOEXEC.BAT file. Scary, huh? You can create a modal dialog easily enough -- add a button and add the following to its OnClick event handler: procedure TMyFormX.Button2Click(Sender: TObject); begin AboutBox; end; You can, if you like, add two listboxes and implement drag and drop between them, a TMediaPlayer and a TOpenDialog components to create wave file player, or anything else you want. The key to remember is that the ActiveForm will run as a process on the client machine, and that none of your code should depend on knowledge of the server. The example code included with this paper contains code that demonstrates a number of techniques that you can use in ActiveForms. A later section will discuss using database controls and providing data over a network or the Internet. Development Issues Developing and debugging ActiveForms can present some interesting challenges. Because you are relying on Internet Explorer to run your ActiveForm, you are at its mercy when it comes to executing your code. The good news is that Delphi makes things a bit easier by allowing you to debug your ActiveForms. You can debug your ActiveForm applications by setting MSIE as the host application for your OCX. This is done by selecting Run|Parameters and entering the path to Internet Explorer as the host application. Now, once your ActiveForm is deployed, if you click on the run button, Delphi will execute IE. Once it is open, you can navigate to the page that displays your ActiveForm, and if you've set any breakpoints, Delphi will debug your code when it runs into one. Occasionally, your code may crash and exit abnormally. In this case, your OCX may remain in memory and in IE's cache. In this case, you'll need to call REGSVR32 on the OCX, passing the /u switch and the full pathname of the OCX. This program can be found in your \WINDOWS\SYSTEM directory (\WINNT\SYSTEM32 on Windows NT). This will unload the ActiveForm and allow you to overwrite any changes that you make with the new file. Normally, you'll need to unload the version of the control that resides in the \WINDOWS\OCCACHE directory. IE can be a bit fickle as well, so if you are having trouble getting the latest version of your ActiveForm to display, try unloading it using REGSVR32. The process of developing an ActiveForm is not as easy as you might like. If you view your ActiveForm and then make changes, you have to shut down IE and reopen it for the new version to be displayed. Including Version Information as a deployment option and in the HTML code will also help IE to download the latest version of your ActiveForm. The easiest way might be to set IE as the host application and run it from the Delphi IDE. Make sure to deploy the application between changes and to shut down IE between sessions or you won't see the latest version of your ActiveForm. Techniques Building ActiveForms requires a bit of a different perspective with respect to the user interface. The first thing to remember is that users are not used to dialog boxes popping up on top of their web browsers. The normal browser interface presents everything a user needs inside the browser. Though you can cause an ActiveForm to create a modal dialog box, you should do so sparingly, as this may confuse users who are not used to such things. Secondly, when designing your forms, you should remember that there is no guarantee of the setup of the user's system. As a result, you should be careful not to use any extravagant fonts, or create a form that will only appear properly at higher resolutions. Make sure your form runs inside MSIE at 640x480, and your form should appear normally on almost any system. Below are a few design techniques that you may want to consider when designing your ActiveForms. Tabbed Notebooks Rather than use popup dialogs which can confuse the user, you may want to consider a TTabSheet with multiple pages. This will enable you to place information in discreet windows like you might with popup dialogs, but still allow the user to access the entire application from a single browser view. If you have a Wizard type control, these can also be effective for dividing up your user interface while keeping an ActiveForm to a single web page. Modal Dialogs Nevertheless, there is no reason that you cannot create modal dialogs. As a matter of fact, you can, and they are built and created exactly the same way in ActiveForms as they are in a regular application (The AboutBox example above illustrates this). If you decide that the TTabSheet approach won't work for your application, then you can add a new form to the project, edit it, and then create and display it exactly like you would in a standard Delphi project. One thing to note, however, is that an ActiveForm is not capable of auto-creating your form; therefore you must manually create any forms that your ActiveForm displays. Another thing to be wary of is the use of non-modal forms. Users are already unaccustomed to web applications producing dialog boxes, so you'll want to be very careful not to present them with a non-modal form that can easily disappear behind their web browser. Lost forms like that can doubly confuse a user not normally accustomed to having to keep track of forms created by a browser-based application. Appearance Delphi creates a default HTML page for you when you deploy your ActiveForm. However, you almost certainly do not want to accept the default settings placed in that HTML file. The default HTML page will no doubt look something like this: Delphi ActiveX Test Page /H1 You should see your Delphi forms or controls embedded in the form below. codebase="./ActiveFormProj.ocx#version=1,0,0,0" width=350 height=250 align=center hspace=0 vspace=0 The meat of the file is, of course the tag, which defines how the ActiveForm is displayed in the user's browser. You will probably want to manually adjust the parameter values for the size and location of the ActiveForm. You can set the Height and Width parameters to the actual pixel values of the ActiveForm itself, or you can set them as a percentage in order to force the form to take up a certain percentage of the browser's viewing area. The hspace and vspace tags determine where the upper left corner of the form are located relative to the location that the form would take up. (These last two tags make more sense if the align parameter is set to something other than center.) As far as the placement of the ActiveForm in an HTML page, the tag behaves like any other standard HTML tag, and you can wrap text or graphics around your ActiveForm like any other HTML element. Manipulating the Browser There may be times when your ActiveForm will want to manipulate the browser itself, either by calling another web page or downloading a file. Delphi includes a unit, URLMON.PAS, that includes procedures for dealing with the browser in which an ActiveForm is running. The most common thing that you will want to do inside an ActiveForm is to change to another URL in the web browser. The following code will call Borland's web site: procedure TActiveFormX.Button1Click(Sender: TObject); begin HLinkNavigateString(IUnknown(VCLComObject), 'http://www.borland.com'); end; Deploying an ActiveForm Getting Ready In order to deploy and work with ActiveForms, you are going to need a specific setup. You will need access to a web server -- any one will do, really. You will need to be able to copy files to a directory that the web server can access. You will also need the most recent version of Microsoft's Internet Explorer. (There is a plug-in available that allows Netscape to run ActiveX controls, but MSIE is the most reliable way to do so right now). If you plan on using ActiveForms to transfer data across a network, then you will have to have DCOM (Distributed Common Object Model) installed on both the server and client machines. Windows NT 4.0 contains DCOM by default. Microsoft provides DCOM for Windows95 as well. It can be downloaded at http://www.microsoft.com/oledev/olemkt/oledcom/dcom95.htm Lots of Options Delphi provides a wizard to ease the deployment of your ActiveForm. It allows you to completely configure the parameters for deploying your application. If you have an ActiveForm open in the IDE, then selecting Project|Web Deployment Options will bring up the Web Deployment Options dialog box. It has four tab pages, one for each aspect of deploying your ActiveForm. Note that this dialog will not deploy your ActiveForm across the Internet, i.e. it won't FTP your application. Instead, this dialog is designed to deploy your ActiveForm across a network. It assumes that you will be deploying your ActiveForm to an Intranet. For example, it allows you to point to any directory on the network for the location of the OCX control and the HTML page. Normally, then, you would develop your ActiveForm on a network client and deploy it to a directory referenced by your web server. If you need to deploy the ActiveForm across the Internet you'll need to manually FTP the needed files with an external FTP tool. Note as well that you can deploy ActiveForms to any type of server. Since the browser will download and run the ActiveForm, you can deploy the OCX to a UNIX-based website, which will gladly serve the *.OCX file to the client. All of the discussion here will assume that you are a developer on a network client, building ActiveForms for a web site running on a server on your network. Simple Deployment Deploying a simple ActiveForm is quite straight forward, and only requires that you enter data on the Project page of the Web Deployment dialog. The most important information is found in the Directories and URLs groupbox. These three edit boxes tell Delphi where the control is going to go and allows it to configure the needed HTML file and copy the files to the given location. They should be filled in as follows: Target Dir -- This edit box should contain the directory where the OCX file is to be copied. You can use the browse button to select a directory on your machine or across the network. Whichever directory you choose is where the OCX file will end up. It should be a directory that is aliased by your web server, so that users can reference it relative to the server's URL address. Target URL -- This entry is the trickiest one, as it requires you to think in terms of the client and not the server. This entry should contain the location of the OCX control from the client's point of view. This entry will be entered into the HTML file and will tell the client where the OCX file can be found. This entry can be a full http entry or a directory relative to the HTML file itself. If you choose to place the HTML file and the OCX in the same directory, then this entry should simply be './' to indicate the current directory. You can edit the resulting code if you like to remove that reference, but the dialog won't let you leave this entry blank, and './' has the same effect as no directory entry at all. HTML Dir -- This entry should contain a directory into which the HTML file is to be placed. When Web deploying, Delphi will build a test HTML page that displays you ActiveForm, and this entry tells Delphi where to place that file. Again, this should be a directory referenced by your web server. Most often, this entry will be the same as the Target Dir entry above. If you have an active form ready to deploy, merely fill in the above items and then select Project|Web Deploy, the form will be deployed to the selected directory as a simple OCX, along with an HTML file that contains the code to display the ActiveForm. It can now be viewed. If you open Internet Explorer and point it to the address of the new HTML page, you should see your ActiveForm displayed. Deploying with Packages and Additional Files Of course you are not always going to want to deploy a complete OCX across your network or the Internet, especially if your site has a number of ActiveForms and ActiveX controls. Just as with any regular application, you can compile your ActiveForm to take advantage of packages. By using VCL30.DPL or VCLDB30.DPL and deploying them with your ActiveForm, you can reduce the amount of data needed to be downloaded. This is especially true if your site uses a large number of ActiveForms. You can load your packages once, and then deploy very small ActiveForms that take advantage of package technology. Of course, in order to do this, your ActiveForm project itself must be compiled using packages. To deploy packages with your ActiveForm, select the Packages tab on the Web Deployment Options dialog. The dialog will automatically list the packages upon which your ActiveForm is dependent. You can select each needed package and determine how it will be deployed. Without compression (which is discussed in the next section), your only option is whether to include versioning information about each package with the project. If you set your project to use packages in the Project Options, the Web Deployment dialog will recognize this and automatically list the needed packages on its Packages page. This page will also allow you to include the versioning information for the packages as part of your project. Choose Use File VersionInfo from the output options group box. This option will take the version info from the resource in the selected package file and enter it into the HTM or INF file that is deployed with the project. The two edit boxes at the bottom of this page allow you to tell the server where the needed files can be found. The Target URL edit box tells the project what the URL of the package is relative to your web server so that the HTML code can find the package for downloading to the user's machine. The Target Directory edit box tells the project where the package is to be placed when the compression is done. This directory would normally be the same location as the HTML file and the OCX itself. This tells Delphi where to go to find the file so that it can deploy it to the web site. Both of these controls can be left blank, which tells the project that they are already available on the target machine and need not be copied. One item of note -- you can, if you like, reference copies of VCL30.CAB and INET30.CAB which are available on Borland's web site at http://www.borland.com/vcl30.CAB http://www.borland.com/inet30.CAB These files are code-signed by Borland and can be referenced directly in the Target URL if you want to save space on your own server. Many times your project will require other external files for proper functioning on the client. For instance, if your ActiveForm uses BDE functions, you'll need to deploy the DBCLIENT.DLL file along with the ActiveForm. You can select and add these additional files on the tab of the Web Deployment dialog. You deploy these files with the same options and in the same way as those that are on the Packages tab. Now if you select Project|Web Deploy, the packages needed by your OCX will be deployed to the client machine. Once the packages are deployed, you can deploy package-based OCX files across the Internet, saving a lot of bandwidth. Deploying Compressed Files Of course, packages themselves are not small, so deploying them through a modem can be quite a task. Naturally, you will want to compress them before deploying, and have them uncompressed on the other side. Fortunately Delphi and Internet Explorer provide this functionality for you. If you select the Use CAB File Compression checkbox on the Project tab of the Web Deployment dialog, Delphi will use the compression technique to reduce the size of the files that your ActiveForm needs to transmit over the network or Internet. If you deploy compressed files, MSIE will automatically uncompress them and make them available for execution on the client side of the process. This procedure can save your users quite a bit of time when downloading your ActiveForm-based web pages. It will also save you space on your server if that is an issue. Once you've chosen the compression option, the Packages page will allow you to decide where the files will be compressed. You can place each package inside the project CAB file -- i.e. the CAB file with the OCX inside, or in a separate CAB file for each package. Code Signing One way that Microsoft provides a modicum of security for ActiveX controls provided over the Internet is by code signing and Authenticode technology. Companies such as www.verisign.com provide a digital signature that can be added to your ActiveForms. This signature is recognized by MSIE which displays a certificate describing the signer of the code and verifies the fact that the code has not been altered since it was signed by the user. This doesn't really add any real protection, but it does provide you with a certain peace of mind. More than likely you will feel confident downloading controls that have been code-signed by Borland, Microsoft, or other reputable companies. Individuals can obtain licenses as well, and you can download code form people that you know and trust. Customers can feel confident downloading controls that have been code-signed by their employees or consultants. Once you've obtained an Authenticode digital signature, you can include it with your ActiveForm so that users can see it when downloading your application. If you select the Code Sign Project option, you can add you *.SPC file to the project. You also need to point the dialog box to your private key file so that it can generate a digital key for the digital signature. Your private key will not be deployed with the ActiveForm. If you want information about your company displayed when the certificate is presented to the user, enter that information into the edit box labeled Name of this Application. Adding a URL to the following edit box will present a link on the certificate page that the user can select to go to a page of your choosing. You can also use the dialog to choose between the MD5 or SHA1 hashing algorithms. Once these items are set, the OCX will be signed by creating a hash value based on your private key and the OCX itself. This information is then attached to the file and recognized by IE when the ActiveForm is downloaded. IE will display a dialog box with a certificate in it that will ask the user if he or she would like to download the control. The certificate will contain your company name and a link to your web page if you included that information with the files. Using Database Tools ActiveForms can be used to create database applications to pass data across a network, an intranet or even the Internet itself. Doing so requires that you use Microsoft's Distributed Object Model (DCOM) and the powerful data access tools that Delphi Client/Server provides. With these tools you can easily build multi-tiered applications that can serve data across machines to any type of web application. Creating a Server Application The first step in building a database application using ActiveForms is to build a remote database server. As usual, Delphi does much of the work for you with a wizard that automatically builds a remote datamodule. Open a blank project and select File|New from Delphi's menu (A Remote Datamodule can only be added to an existing project). Then select the Remote Data Module option. Delphi will then open a small wizard that will determine the class name and instancing values for the server. Enter 'TestServer' for the ClassName (Delphi will add the prefix 'T' in the class declaration), and in the Instancing box select 'Multiple Instances' (This last selection will allow multiple clients to access the server). If you only want one client at a time to access the datamodule, then select 'Single Instance", and if the server application is to reside on the same machine as the client, then select 'Internal'. Clicking 'Ok' will then create a TDatamodule descendent that uses the ITestServer interface. This causes the datamodule to become a DCOM application. The ITestServer interface is declared in file PROJECT1_TLB.PAS that Delphi creates as part of the module. You can place any data access components that you need. You can treat this datamodule like one in a regular client/server application, placing business rules, data access, etc., inside it. This application server becomes the middle tier in the traditional multi-tier environment. For demonstration purposes, place a single TQuery in the datamodule, set its DatabaseName property to DBDemos, and add the following to its SQL property: select * from employees Then, right click on Query1 and select 'Export Query1 from Datamodule'. This creates a new method that causes Query1 to return an IProvider interface when called. This will come into play in the next section when TProvider is covered. This allows the dataset created by the query to be accessed by a remote dataset. You can see how the TQuery was exposed in the interface by opening the PROJECT1_TLB.PAS file that Delphi creates when you save the file. Open it in the Code Editor with File|Open and Delphi will display the file with the Type Library editor. Select the ITestServer interface from the Treeview and you can see that the TQuery, Query1, is now a property of the interface. At this point, your application server contains a datamodule and a form. You can leave the form blank, or hide it if you want to. When your server is called, the form will be created, so you can provide some feedback as to the status of the application server via the server form if you desire. See \DELPHI 3\DEMOS\DB\CLIENTDS\SERVER.DPR for an example of this. Now, this basic server application is ready to be accessed. Compile the project, and then run it once on the computer that is your server. This will register the server application and allow it to be found by the client using DCOM. TClientDataSet/TProvider Of course, in order for this server to be useful, it needs a client application to access it. Naturally, an ActiveForm can perform as that client application. To do so, create a new ActiveForm from the File|New menu. Select the Include Version Information option so that any updates you make to the form will be noticed by your web browser. Once the ActiveForm is created, place a TClientDataSet, a TRemoteServer, a TDBEdit, a TDBNavigator, and a TDataSource control on the form. Next, set the properties of those controls as follows: DataSource1.Dataset to ClientDataSet1 RemoteServer1.ServerName to Project1.TestServer (Note that since the server application was registered by running it, this property value can be selected in the Object Inspector, and that the ServerGuid property will be automatically filled in) ClientDataset.RemoteServer to RemoteServer1 ClientDataset.ProviderName to Query1 (By setting ClientDataset.RemoteServer, this property can be picked in the Object Inspector) DBEdit1.Datasource to DataSource1 DBEdit1.DataField to LastName DBNavigator.DataSource to DataSource1 ClientDataSet1.Active to True Once those properties are set, this form is ready to deploy. After deploying the ActiveForm, open it in Internet Explorer. You should be able to see the ActiveForm, and it should display the last names of the employees listed in the EMPLOYEE.DB table that is part of the demo applications that are installed with Delphi. If you want to view this application with a Windows95 client, that client must be properly configured to use DCOM for Windows95. Conclusion ActiveForms are a powerful and capable technology that can enhance your Internet and Intranet development capabilities. They can provide client applications to users across any network. They can even use database controls to run a data-based application across the network. ActiveForms present unique development and deployment issues. Fortunately, Delphi makes building and deploying ActiveForms a relatively straight-forward task.