Limitations of ActiveX Control Hosting

Limitations of ActiveX Control Hosting

If you have ever used an ActiveX control in an environment outside Visual Basic, such as Microsoft Internet Explorer or Microsoft Office, you might have encountered differences or limitations in behavior for that control. Likewise, a .NET Windows form is a unique control host environment with its own capabilities and limitations. Since a .NET Windows form is primarily the host container for .NET components, some interesting magic is cast on an ActiveX control to make it act as if it were a .NET component. Unfortunately, this magic has limited power and cannot be applied to all types of ActiveX controls. Therefore the Windows Forms environment offers no support for the following types of ActiveX controls and components:

  • Container controls

  • Windowless controls

  • DAO-based data-bound controls

  • Controls that make use of internal Visual Basic 6 interfaces

  • Components that hook into the Visual Basic 6 extensibility model

  • ActiveX designers

We discuss each of these in turn in the sections that follow.

Container Controls

The SSTab ActiveX control is an example of a container control. Although you can place an SSTab control on a Windows form, you cannot place other controls within the SSTab. Part of the problem is that the SSTab control needs to communicate with the controls placed inside it. The communication happens using ActiveX interfaces that are not supported by a .NET Windows form. The end result is that the SSTab cannot find the child controls. Moreover, it cannot associate each child control with the tab to which it belongs. The ability to display contained controls on separate tabs an essential feature of the SSTab control is lost.

note

The Visual Basic .NET Upgrade Wizard automatically replaces each instance of the SSTab control with a .NET Windows TabControl. This is one of the few cases in which the Upgrade Wizard replaces an ActiveX control with an equivalent .NET control. Since the SSTab control is dead weight on a Windows form, the Visual Basic team decided to give you a head start. You will find that all of the child controls on each SSTab tab are moved to the appropriate TabControl tab. You are left to focus on changing top-level properties of the TabControl and tweaking some code. Otherwise, you would be spending hours meticulously re-creating and placing each child control on each TabControl tab exactly as it appeared in the SSTab control.

Windowless Controls

The Windows Forms environment provides support only for controls that display within a standard window. To support windowless controls, a host needs to support painting the control directly within the form window. One nice feature is that windowless controls can be made transparent, since the host manages the painting for the control and the form on the same window surface. A side effect of Windows Forms not supporting windowless controls is that you cannot create transparent labels, as you could in Visual Basic 6.

In most cases the lack of support for windowless controls will not prohibit you from placing a windowless control on a Windows form. Most windowless controls have a split personality of being either windowed or windowless, depending on the capabilities of the host. If the host supports windowless controls, the control will take on its preferred windowless form. If the host does not support windowless controls, the control will take on its less desirable, but workable, windowed appearance. In the case of Windows Forms, all windowless controls will be asked to create a window and render as a windowed control.

DAO-Based Data-Bound Controls

DAO-based data-bound controls include the Visual Basic 5 DBGrid and RDO Data control. Visual Basic 6 links these controls to their data source using an internal data binding manager object. Visual Basic .NET contains no such internal data binding manager object and so provides no such support for DAO-based controls. Therefore, you will find that you cannot bind a DBGrid control to an RDO Data control in Visual Basic .NET.

ADO data binding works just fine. The data binding manager object for ADO is contained in an ActiveX component called MSBind. This component enables you to bind ADO components such as the Visual Basic 6 DataGrid to ADO data sources such as an upgraded DataEnvironment class.

Controls That Make Use of Internal Visual Basic 6 Interfaces

A limitation of the ActiveX architecture is that it does not provide a standard mechanism permitting controls to find one another on the same form or document. It is left up to the host to define interfaces that allow controls to hook up with one another. Visual Basic 6 defines interfaces such as IVBGetControl that allow ActiveX controls to find their parent, children, or siblings. Visual Basic .NET does not provide full support for these interfaces. As a result, controls that depend on other controls will not work properly. For example, the UpDown ActiveX control becomes more or less a paperweight in the Visual Basic .NET environment. You can attempt to buddy the control to another control, but you will find that the values for the buddy control will not update when you click the UpDown control. In this case, it is recommended that you use the .NET Framework UpDown control instead.

Components That Hook into the Visual Basic 6 Extensibility Model

Don t expect to be able to use a Visual Basic 6 add-in component in the Visual Basic .NET environment. Add-in components such as wizards generally interact with the development environment to create controls, change code, and update project settings. The component interacts with the environment through a set of extensibility interfaces. The problem is that Visual Basic .NET supports a completely different set of extensibility interfaces than Visual Basic 6 does. Visual Basic 6 add-in components simply will not work in the new environment.

ActiveX Designers

ActiveX designers such as the DataEnvironment, WebClass, DHTML, and DataReport Writer are not supported in Visual Basic .NET. The Microsoft Visual Studio .NET environment supports a completely different approach to designers known as packages. None of these designers are provided as Visual Studio .NET packages. In the case of the DataEnvironment and WebClass designers, the Upgrade Wizard will upgrade your Visual Basic 6 DataEnvironment and WebClass projects to take advantage of run-time support classes for these designers. This means that your projects based on DataEnvironment and WebClass can be made to work at run time, but you will not get a fancy designer that you can use to change settings at design time. All settings must be changed by writing code.



Upgrading Microsoft Visual Basic 6.0to Microsoft Visual Basic  .NET
Upgrading Microsoft Visual Basic 6.0 to Microsoft Visual Basic .NET w/accompanying CD-ROM
ISBN: 073561587X
EAN: 2147483647
Year: 2001
Pages: 179

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net