Mirror

ActiveX Intranet (Views: 708)

Problem/Question/Abstract:

Building ActiveX Controls for the Corporate Intranet

Answer:

Delphi is an excellent construction yard for ActiveX controls, but little attention has been paid to ActiveX for Web applications since their splashy failure in the industry. As a general-use Internet application delivery system, ActiveX is unsatisfactory. The size, platform-specific nature, and potentially hazardous content (from unknown suppliers), all conspire to deny it wide acceptance as an Internet platform. Few users would appreciate the 20 minutes of download time, simply to have the application they wanted crash - and take their machine with it.

These problems, however, are essentially alleviated within the corporate firewall. Size and platform independence, the primary failings of ActiveX, don't matter much within a corporation where 10-megabit network connections and Win32 desktops hold sway. Additionally, with site-specific security measures available, supply of Active content to a user's desktop can be limited to an organization's "trusted" sites. In this context, ActiveX offers several benefits not available to Java, its primary competition:

It's cached. OCX files brought down from the Web are brought once, assuming cache-time and disk allotment aren't exceeded. Java code must be downloaded and run with each hit to a Java-enabled site.
It's fast. ActiveX files are compiled code, and run natively as extensions to the clients' browsers. Java, to date, is interpreted (there are some exceptions for JIT compilers and the JBuilder native compiler), and takes between five and 20 times the amount of time to provide identical functionality if achievable.
It can be 100 percent Delphi. One of the things I dislike about Java is that - it's Java. I took up Delphi specifically because I didn't want to learn C. Perhaps I'm lazy, but I am reticent to give up the skills it's taken me a few years to develop. JBuilder is a great product, and I do see a future in Java, but I don't want to learn the syntax. Installed development shops that have a lot invested in Delphi will find the ActiveX route a potential gold mine in resource usage.

It also shares some benefits with Java:

It's instantly updated. As soon as a new OCX file is delivered to the Web site, new hits draw an updated version of the application.
It's thin. That's right, thin. Although even a small ActiveX application deploys at around a half a megabyte (the sample application in this article deploys at 1078KB), when deployed with run-time packages, that total can shrink to something really puny (the sample mentioned deploys to 337KB under run-time packages). There's an additional benefit in using CAB file compression (more on this later).
It can be n-tier. In fact, I recommend this highly. Because the user has a network connection already (otherwise he or she would not be able to tag your Web site), there isn't anything that should prevent your application from being aware of a middle-tier server. Using TClientDataSet in your ActiveX application provides two benefits: It maintains the "Ivory Tower" of data control, and further "thins" the application by not requiring a BDE installation or configuration (all this is maintained at the middle tier). If the only requirements are the OCX, some run-time packages, and a copy of Dbclient.dll, your client should be getting downright skinny.

Design

Although it's outside the scope of this discussion, I'd like to stress that design should be the most important aspect of any application effort. Generally, the better the design, the better the final product; a poor design will yield a poor application. Unfortunately, too many developers start coding with little or no planning.

ActiveX applications generally require more effort than conventional applications when it comes to analysis and design. Here are some considerations:

Will the control be solely for Web deployment, or will it be an add-in for other applications? If you're going to pass the control to other developers to use in other tools, you may need to surface some properties and/or methods to make it useful.
What data access route will you take? The Dbclient DLL to connect to a middle tier? Full BDE installation? Will you need to deploy OLEnterprise or MIDAS? Do you even need a database for this application? This is especially important for ActiveX controls, because CAB deployment of OLEnterprise and the BDE require a little more attention than simply shipping disks and/or checking a box in InstallShield.
Does the application contain many features that might not be used often? The concern is keeping the client thin. If some of the functionality of the application (e.g. maintenance forms) won't be used often, pack it away in a DLL and include it in a separate CAB.

Development

First things first: If you want a multiple-document interface (MDI) application, ActiveForms aren't going to be much help. If you already have a means by which to emulate MDI applications in an SDI environment, you'll be all right, but ActiveForms don't have a FormStyle property. If you're good enough with Delphi to descend your own class that supports MDI, you probably don't need to be reading this, so I'm not going to cover it. Since the likelihood is that the application will get tested a few times before completion, we'll need to set up the Web Deployment Options from the Project menu. This will allow us to determine where the application will get dropped by Delphi. It also gives the developer an opportunity to isolate the output from the code directory. Once the settings are satisfactory, the developer can start coding.

We'll probably need some kind of Web server to offer our still-in-development project for our own review. Most of us won't have access to a dedicated test-bed Web server. For this reason, I recommend doing ActiveX Web development on an NT machine with Personal Web Server or IIS. Personal Web Server is available from the Microsoft Web site as part of the NT 4 Option Pack at. There is a version for Windows 95 available from the same site, but I don't recommend doing this kind of work in Windows 95 - certainly not with less than 32MB of RAM.

Using Personal Web Server is fairly straightforward, and it comes in handy for many kinds of design work. It also makes publishing documentation on the code you write fairly easy, and makes it available to you for instant changes.

So how do you develop an ActiveX application? The answer is simple: You don't. Just develop your application as a standard stand-alone Delphi application, using the aforementioned considerations. Then, when it's finished, create an ActiveForm shell. Close your finished project, and create a simple ActiveForm, i.e. select File | New, then choose ActiveForm from the ActiveX page of the Object Repository. Add the files from your normal project to the new ActiveForm project. Delphi creates a new ActiveForm project for you (in many ways, it's similar to a DLL project). Then, simply create the main form of your finished application in the OnCreate event handler of the ActiveForm. Setting that form's parent to the ActiveForm and maximizing it will run your application within the OCX.

This is great when it comes to producing a quick-and-dirty demonstration of an existing application, and the client wants to see a Web-deployment proof-of-concept. You can have a browser-based version of your application in minutes. This example was created over an omelet at IHOP. It might not be so great when you think about possible application architecture issues that haven't considered OCX deployment - particularly if this application wasn't originally intended for Web deployment. Chances are some "weight" will need to be removed (by breaking functionality into DLLs, etc.).

There are some differences between normal development under Delphi and Web deployment. For example, from Run | Parameters, the developer will need to locate the browser (this article was written with IE4 in mind, Netscape users can change paths as appropriate) and insert it in the Host application drop-down. This feature is available both in OCX and DLL development, and allows debugging of your control/application through the host application. (Usually, IE will be found at C:/Program Files/Plus!/Microsoft Internet):

Run | Parameters should also be set to the .HTM file deployed by Delphi when the Web Deploy action is chosen. This isn't necessary if you already have a link to it built into your default page, but can save you from following several tags every time you try running something.
Get accustomed to using Compile or Build All from the menu, then choosing Web Deploy to guarantee you get the latest version of your control. Trusty old [F9] might not be what you're looking for here.
Only the main form needs to be of Active content. All others can be standard TForm descendants. If you add more active forms, Delphi will adjust the .HTM file appropriately, and you'll have a bunch of empty sockets in a very long page - not fatal, but messy.
This method requires slightly more complex project management, and presents difficult unit and system testing of the application.

Build Task One: Create an Active Form Shell

To make this easy, we'll copy a demonstration project from the Delphi 3 installation and turn it into a Web-based application. First, create a new directory for your ActiveX project and copy the contents of the demonstration project into it. I've chosen TeeChart (Program files\Borland\Delphi 3\Demos\TEECHART), because it's flashy and somewhat elaborate. (This article discusses Delphi 3, but this technique works for Delphi versions 3 and higher.)

In Delphi, choose File | New, then ActiveForm from the ActiveX page of the New Items dialog box (see Figure 1). Delphi will generate a new ActiveForm, a type library (which you won't need to worry about for purposes of this exercise), and a project file (which you also won't need to worry much about). Save all these files into the new directory you just created, and give them some meaningful names. (The projects discussed in this article are available for download; see the end of this article for details.)


Figure 1: Creating an ActiveForm shell.

View the project manager (or the project source), and add to the ActiveForm project all the files you chose from the demonstration project. In the ActiveForm, add a private variable to the ActiveForm's class definition corresponding to the class of the main form of the demonstration application:

TAXTeeChartDemo = class(TActiveForm, IAXTeeChartDemo)
procedure FormCreate(Sender: TObject);
private
// Private declarations.
FEvents: IAXTeeChartDemoEvents;
// A var must be included in the type declaration
// for this stunt.
frmTeeMain: TTeeMainForm;
procedure ActivateEvent(Sender: TObject);
{ ...}

You'll also need to add the appropriate unit to the ActiveForm's uses statement, TeeMain is this case. Now, generate a FormCreate event in the ActiveForm, and from there, create an instance of the form into the variable you just declared (e.g. frmTeeMain). Finish by parenting it and giving it some formatting to fit the OCX control:

procedure TAXTeeChartDemo.FormCreate(Sender: TObject);
begin
frmTeeMain := TTeeMainForm.Create(Self);
frmTeeMain.Parent := Self;
frmTeeMain.Height := Self.Height;
frmTeeMain.Width := Self.Width;
frmTeeMain.Show;
end;

Now, go to the Project menu, and choose Web Deployment Options. We'll take this a page-at-a-time later in the "Deployment" section. The Project page is the most important right now. Once the top three entries are made (again, see the section titled "Deployment"), accept this dialog box and select Project | Web Deploy. There's no speed button for this command, so you'll become familiar with [Alt][P][D]. Once Web deployment is complete, you can tag the .HTM file directly from Explorer, or follow a link you build into your Web site (see the section titled "Link It All In"). The result is shown in Figure 2.


Figure 2: The TeeChart demonstration application as an ActiveForm.

Generally, following the route of a normal application works just fine - with no concern over browser location, .HTM links, etc. Simply build the application as you want it. When finished, re-create the main form as an ActiveForm by taking a blank ActiveForm and pasting the routines and controls from your original main form into it. Adding in the remainder of the files from the project finishes the task.

Build Task Two: Transplanting the Code

Again, build your application as a standard Win32 application with no regard to Web planning, and test it until you feel it works properly. Then create a new project directory for constructing your new ActiveX application. Next, select File | New and choose ActiveForm from the ActiveX page of the New Item dialog box. Save the resulting files, giving them and the components sensible names.

Now, copy the contents of the application from step 1 into your new application's directory. Open the main form of the original application while you have the ActiveForm project open. Copy the components, events, and methods of the main form into the ActiveForm. This may require re-creating the events (such as button clicks, etc.), but because you've already written the code, creating the event handlers should be a pretty rudimentary task. Don't modify anything Delphi generated for you, unless you know exactly what you're doing. Continue with deployment as described in Build Task One.

Deployment

Okay, we've got the application built. Now comes the part where we have some tricks to pull. Deployment of an ActiveX application is fairly simple, but there will be some problems with how Delphi creates some of the output.

The Web Deployment Options dialog box is where you tell Delphi how you want your application deployed on a Web page (see Figure 3). It's a good idea to complete this early - as one of the first steps in creating your Web application - then you don't have to worry about it once the code starts flying.


Figure 3: Web deployment options.

The options begin with the Project page where you determine the physical location of the deployed project. Target dir indicates where the CAB or OCX files will be placed. You can supply either a direct drive-mapped path or a UNC path, e.g. C:\Projects\ActiveX Test\Output. HTML dir indicates where the .HTM file will go as a drive-mapped path or UNC, e.g. C:\Projects\ActiveX Test\HTML. Target URL is the listing that will be placed in the .HTM file as a URL path on the Web server, e.g. http://LocalHost/ActiveXApplication.

There are also General Options to consider on this page: Use CAB file compression ought to be used, regardless of the size of the OCX file. Simply put, this crunches down the size of the download to a smaller file (generally between 50-75 percent of its original size), and makes it a little faster to download. This is particularly useful when dealing with users who will be accessing your application with a modem.

Regarding the Code sign project option: Code signing isn't terribly important within an intranet, but a couple of things need to be pointed out about code signing. First, it isn't terribly expensive, so if you intend to serve this application outside the firewall, get a signature. Corporations such as Verisign can supply digital signature registration at reasonable cost to both large corporations and individual developers. Second, once a signature has been obtained, guard it jealously. Only one developer in a shop should have access to the digital signature, and it should be considered volatile property of the company. I'm no specialist on liability law, but I can certainly tell you that a disgruntled employee who Web-deploys "format C:\" with a code signature from your company is going to cause a lot of problems.

The Deploy additional files option will probably be necessary, especially if you build your application with run-time packages or DLL files. The Packages page (see Figure 4) will specify those packages used by your ActiveForm project. Each package will be individually configurable to determine whether it's Compressed in project CAB, or Compressed in separate CAB file. It's recommended you use separate CAB files to avoid having to send an overly-large project file, if all that has changed was the project. You can also determine whether to Use file VersionInfo, and provide Target directory and Target URL information. By default, package CAB files will use the same target URL and directory as the project CAB. This doesn't change the fact that they'll probably be loaded into one of the cache directories, unless you send them elsewhere by specifying their destination in the INF file.


Figure 4: The Packages page specifies packages used by your ActiveForm project.

The Additional Files page is, where necessary, non-package files are included (see Figure 5). These have the same options and notes as package files; basically this page is included to allow the developer to add run-time files that Delphi isn't normally aware of. This is where the BDE and OLEnterprise installation CAB files should be added to the project, if they're required.


Figure 5: The Additional Files page is where needed non-package files are added.

The developer may wish to consider including a configuration file with the OCX application, to allow the user to connect directly to a server via TCP/IP upon running the application. In the ideal circumstance, the application reads the supplied configuration file, sets its TDatabase, TRemoteServer, or TMIDASConnection control appropriately, and saves its settings to the registry. The TCP/IP stack should already be present (or the user wouldn't have been able to download the application), and the application can check for its settings in the registry before reading the configuration file.

Code signing is provided to allow the developer to specify the details of the signature file (see Figure 6). Again, any use of a code signature should be carefully governed. Consider it the endorsement of your company (or yourself, if you're a sole developer).


Figure 6: Code signing is provided to allow the developer to specify the details of the signature file.

That's Web deployment configuration. Not too bad once you've been through it once or twice. There'll be several additional files generated in the project. MyApplication.INF is an information file containing an entry for every file to be deployed to the Web server for your application to run. It'll look something like this:

;Delphi-generated INF file for UnzipProjX.ocx
[Add.Code]
UnzipProjX.ocx=UnzipProjX.ocx
dunzip32.dll=dunzip32.dll

[UnzipProjX.ocx]
file=http://localhost/UnzipProjX.cab
clsid={ 33F47DC3-A735-11CF-A090-00A024B18D7A }
RegisterServer=yes
FileVersion=1,0,0,0

[dunzip32.dll]
file=http:// localhost/dunzip32.cab
FileVersion=1,0,0,0
DestDir=11

This file contains information on where to find the individual files to be deployed with your OCX-based application. The file= entry of each section denotes the CAB file containing the file for this section. The clsid entry refers to the GUID of any ActiveX file (in the previous example, only the application had Active content to require a GUID). RegisterServer specifies whether the control should be registered with the operating system. FileVersion denotes whether the CAB file will be downloaded to the client. If the CAB file found has a version earlier than the FileVersion entry, it won't be sent.

Delphi won't place a DestDir entry in your INF file; the developer must add it by hand. DestDir indicates the location of the file installed by the browser. By default, the OCX file will be dropped into one of the browser's cache directories; should other files be placed there as well, the application may not know where to find them. DestDir can specify different directories, other than the cache directories. Specifically, a value of 10 indicates the Windows OS directory (e.g. C:\Windows on a default Win95 machine, or "C:\Winnt on a standard NT box), while a value of 11 directs the file to the system directory (e.g. C:\Windows\System, or  C:\Winnt\System32 respectively). This is very important, as package files and DLLs must be found by the application at run time.

The .HTM file (e.g. MyApplication.HTM) is the HTML "wrapper" that will refer to the OCX file generated by Delphi. It will appear like this:


Delphi ActiveX Test Page


You should see your Delphi forms/controls in the form below.


"c:\MyAppDirectory\ActiveFormName.cab#version=1,0,0,0"
width=[width of your ActiveForm]
height=[height of your ActiveForm]
align=center hspace=0 vspace=0>



This defines how your ActiveForm application will display itself in the user's browser. Referencing this HTML file with a link from another page is all that is necessary to connect your new application with the outside world.

If you find more than one reference in your HTM, it probably indicates you've generated more than one ActiveForm in your application. This is a mistake I made early on. Only the Main form needs to be of the Active variety. All the other forms in your application can be standard TForm descendants with no special attributes.

Other files created as a result of your Web deployment will include the usual DCUs (unless you're a fan of OBJ files), RES, DOF, and backups. Additionally, you'll see an OCX and a CAB file in the target directory. If the output directory is one that doesn't get linked directly by your Web server, the files you'll need to place in reach of the Web server are: any CAB files, MyProject.HTM, and MyProject.INF. The only link necessary to your project is to the HTM file. The CAB and INF files will take care of themselves.

Link It All In

Now that we've gone over the bits and pieces, we only need to link to our HTM file, and hit it with a browser. Internet Explorer users won't have a problem with Active Content (other than the security settings described later in this article).

Security in IE will need to be adjusted to accommodate your testing. I've found the easiest way to accomplish this is to make your host machine a "trusted site," and give trusted sites rights to do whatever they please. The clients downloading your finished product probably can do this as well, because we're talking about intranet deployments, but anyone hitting your control from the Internet might not be so trusting. They will need to adjust specifically to deal with your application.

The security settings in Internet Explorer can be accessed from the View menu, under Internet Options. The second page of the Internet Options dialog box is devoted to security. In it, any user who needs to access the ActiveX application will need to be able to both download and script the ActiveX control containing the application. Depending on whether the ActiveX application is signed, the security settings for the appropriate status of the control should be set to enable or prompt. Generally, I recommend prompt, but you might get fed up with having to answer "yes" all the time while developing. It's your call how you handle this, but do be careful about accidentally enabling download of content from anywhere on the Internet.

IE4 users have several security zones from which to choose. As this topic is geared toward the corporate intranet, low security settings on the local intranet zone are recommended, and as I've previously mentioned, it probably would be easiest to add your local host to the trusted sites list. For any Internet zone, however, I certainly recommended that the browser should at least prompt the user for download and scripting of content from any site not in the trusted list.

Conclusion

Hopefully, I've made this fairly simple. Creating an ActiveX application is different and sometimes frustrating, but generally not much different from creating a standard Windows application. I've found configuration of the developer's workstation and deployment issues constitute the main additional effort when dealing with ActiveX applications. With luck, you'll be publishing on the Web in a few hours, and your boss will be more than happy with the splashy content you'll be able to generate. I wish you luck. E-mail me if you have any great success stories with this; I'd like to hear about them.


Component Download: http://www.baltsoft.com/files/dkb/attachment/ActiveX_Intranet.ziphttp://www.baltsoft.com/files/dkb/attachment/ActiveX_Intranet.zip

<< Back to main page