Share via

Visual Basic Concepts

  • Article

Designing Controls for Use With HTML

A control on an HTML page is specified using the HTML <OBJECT> and </OBJECT> tags. When the HTML is processed, the control is created and positioned. If the <OBJECT> tag includes any <PARAM NAME> attributes, the property values supplied with those attributes are passed to the control's ReadProperties event using the standard PropertyBag object, as discussed in "Understanding Control Lifetime and Key Events."

Once the HTML page is active, the control's property values may also be set by scripts attached to events that occur on the page.

Note   If there are no <PARAM NAME> attributes other than those that set extender properties (such as Top and Left), the control may receive an InitProperties event rather than a ReadProperties event. This behavior is dependent on browser implementation, and should not be relied on.

The Package and Deployment Wizard makes it easy to create an Internet setup for your control, with cabinet (.cab) files that can be automatically downloaded when a user opens an HTML page containing an instance of your control. Support files, such as MSVBVM60.DLL, can be downloaded separately. P-code .ocx files are very compact, so if support files already exist on a user's computer, downloading can be very fast.

Visual Basic controls can support digital signatures, safe initialization, and safe scripting.

Important   In order to use a control that includes licensing support on an HTML page, a licensed copy of the control component must be installed on the Web server that provides the page. This is discussed in "Licensing Issues for Controls," later in this chapter.

Making Your Control Safe for Scripting and Initialization on HTML Pages

Code that's downloaded as a result of opening a page on the World Wide Web doesn't come shrink-wrapped, blazoned with a company name to vouch for its reliability. Users may be understandably skeptical when they're asked to okay the download. If you intend for your control to be used on HTML pages, there are several things you can do to reassure users.

  • Digital signatures create a path to you (through the company that authorized your certificate), in the event that your control causes harm on a user's system. You can incorporate your signature when you use Package and Deployment Wizard to create an Internet setup for your control component.

  • Marking your control safe for scripting tells users that there's no way a script on an HTML page can use your control to cause harm to their computers, or to obtain information they haven't supplied willingly.

  • Marking your control safe for initialization lets users know there's no way an HTML author can harm their computers by feeding your control invalid data when the page initializes it.

This topic explains how to design your control so that when you create your Internet setup, you'll be able to mark your control as safe for scripting and safe for initialization.

Note   The default setting for Internet Explorer is to display a warning and to refuse to download a component that has not been marked safe for scripting and initialization.

For More Information   The latest information on digital signatures, cabinet files, and Internet setup can be found on the Microsoft Visual Basic Web site.

Safe for Scripting

When a Web designer places your control on an HTML page, he uses a scripting language such as JavaScript or Visual Basic, Scripting Edition to access the control's properties, invoke its methods, and handle its events. By marking your control as safe for scripting, you're providing an implicit warrantee: "No matter what VBScript or JavaScript code is used, this control cannot be made to harm a user's computer, or to take information the user hasn't volunteered."

As the author of your control, you can be reasonably sure that in normal use it won't destroy data or compromise the security of a user's computer. Once your control is in the hands of a Web designer, however, you have no guarantee that it will be used in the ways you intended.

Keys to Scripting Safety

As an example of a control that's not safe for scripting, consider the rich text box. The RichTextBox control has a SaveFile method that can be used to write the contents of the control to a file. A malicious person could write a script that would cause this control to over-write an operating system file, so that the user's computer would malfunction.

What makes the control unsafe is not that it can save information to a file — it's the fact that the script can specify the filename. This observation provides the key to creating controls that are safe for scripting. As long as your control doesn't allow a script to specify the source or target for file or registry operations, or make API calls that can be directly controlled by a script, it is probably safe for scripting.

Thus, a control that permits a Web page designer to do any of the following is probably not safe for scripting:

  • Create a file with a name supplied by a script.

  • Read a file from the user's hard drive with a name supplied by a script.

  • Insert information into the Windows Registry (or into an .ini file), using a key (or filename) supplied by a script.

  • Retrieve information from the Windows Registry (or from an .ini file), using a key (or filename) supplied by a script.

  • Execute a Windows API function using information supplied by a script.

  • Create or manipulate external objects using programmatic IDs (for example, "Excel.Application") that the script supplies.

The line between safe and unsafe can be a fine one. For example, a control that uses the SaveSetting method to write information to its own registry key doesn't disqualify itself for safe scripting by doing so. On the other hand, a control that allows the registry key to be specified (by setting a property or invoking a method) is not safe.

A control that uses a temporary file may be safe for scripting. If the name of that temporary file can be controlled by a script, then the control is not safe for scripting. Even allowing a script to control the amount of information that goes into the temporary file will make the control unsafe for scripting, because a script could continue dumping information into the file until the user's hard disk was full.

As a final example, a control that uses API calls is not necessarily unsafe for scripting. Suppose, however, that the control allows a script to supply data that will be passed to an API, and doesn't guard against oversize data overwriting memory, or invalid data corrupting memory. Such a control is not safe for scripting.

As an indication of the seriousness of scripting safety, note that VBScript itself does not include methods to access the registry, save files, or create objects.

Choosing Constituent Controls

You might think that using a constituent control that's not safe for scripting would automatically make your ActiveX control unsafe for scripting. This is not necessarily true.

As explained in "Adding Properties to Controls," later in this chapter, the properties and methods of constituent controls do not automatically become part of your control's interface. As long as you avoid exposing the properties and methods that make a constituent control unsafe, you can use it without making your own control unsafe.

For example, if you use the RichTextBox as a constituent control, you should not expose its SaveFile method.

Important   Do not provide a property that returns a reference to an unsafe constituent control. A script could use this reference to access the properties and methods that make the control unsafe.

Documenting Scripting Safety

Determining whether a control is safe is not a trivial exercise. You may find it helpful to record your design decisions that affect safe scripting. A useful exercise is to construct tables containing the following:

  • All of your control's public properties, methods, and events.

  • All of the files and registry keys accessed, and all API calls used.

If there are any dependencies or data transfer between the elements of these two tables, then the control is probably not safe for scripting.

You may wish to have this documentation reviewed by an experienced programmer who understands both ActiveX controls and scripting.

Safe for Initialization

A control marked as safe for initialization carries an implicit guarantee that it will cause no harm no matter how its properties are initialized.

On an HTML page, your control's initial state is set using PARAM NAME attributes with the OBJECT tag that embeds your control on the page. If a malicious Web designer can make your control steal information or otherwise cause harm by placing invalid data in a PARAM NAME attribute, then your control is not safe for initialization.

The best defense against malicious data is to validate each property value that's obtained in your control's ReadProperties event. All the data a Web designer places in PARAM NAME attributes is supplied to your control through the PropertyBag object in the ReadProperties event. (A well-written control should perform this kind of validation anyway, to prevent problems caused by developers who manually edit .frm files.)

For More Information   The most up-to-date information on authoring controls for the Internet can be found on the Microsoft Visual Basic Web site.

Using Show and Hide Events

The Show and Hide events can be very useful on Web pages. If your control is performing a resource-intensive task, such as showing a video clip or repeatedly downloading and displaying a stock value, you may want to pause this activity when the Hide event occurs.

The Hide event means that the user has moved on to another page, relegating the page your control is on to the History list. The Show event means that the user has returned to your page, and can thus be the signal for resuming resource-intensive display tasks.

For More Information   The Show and Hide events are discussed in "Understanding Control Lifetime and Key Events," earlier in this chapter.

Using the Parent and ParentControls Properties

You can use the Parent property of the UserControl object to access the container. For example, in Internet Explorer, the following code will change the background color of the HTML page on which your control is located:

Parent.Script.get_document.bgColor = "Blue"

More information on the Internet Explorer Scripting Object Model can be found on Microsoft's Web site.

Important   Always use late binding for calls to the Internet Explorer Scripting Object Model. Using early binding will almost certainly cause compatibility problems in the future, while late binding will always work.

The ParentControls Collection

The ParentControls collection allows you to access the other controls on a container where your control has been sited. On some containers — Internet Explorer is one of them — ParentControls returns an extender object whose properties and methods are not merged with those of the controls. This prevents you from accessing the controls themselves.

To access the other controls on an HTML page, you can set the ParentControlsType property of the ParentControls collection to vbNoExtender. The ParentControls collection will thereafter return the interfaces of the controls themselves, without the extender.

ParentControls.ParentControlsType = vbNoExtender

Note   The Parent property and ParentControls collection can be used with many other containers. They are not limited to HTML browsers.