Benefits of Upgrading Controls

Benefits of Upgrading Controls

Upgrading from ActiveX controls to Windows Forms controls has certain benefits. As you ll see in this section, these benefits include 100 percent Microsoft .NET compatibility, improved versioning, and simpler deployment.

100 Percent .NET Compatibility

Windows Forms controls have an inherent advantage over ActiveX controls in that they are native to the .NET environment, and thus they are more tightly integrated into that environment. For example, a Windows Forms control can support custom property editors such as a TreeView nodes collection editor for use with the Property Browser.

Because ActiveX controls are based on COM and are not native to the .NET environment, you may encounter some issues with them. For example, custom property editors are not available for ActiveX controls. An ActiveX control may depend on functionality provided by the Visual Basic 6 environment, which does not exist in Windows Forms. Thus, the capabilities of the ActiveX control may degrade when placed on a Windows form. For example, the ActiveX SSTab control depends on a specific host interface in order to support child controls. Windows Forms does not support the host interface SSTab is looking for, so the control cannot accept child controls when it exists on a Windows form.

Improved Versioning

You can think of ActiveX controls and components as being global across all applications. When an ActiveX control is registered on your machine, all applications in which the control is used will share the control from the same location. If you download an update for the ActiveX control, all of your applications automatically use the updated control. This global use of controls can be good and bad. It s good if the updated control fixes bugs that affect one or more of your applications, but it s bad if the updated control introduces new bugs or incompatibilities that break your applications. Because accepting an update for an ActiveX control is an all-or-nothing proposition, the potential for doing more harm than good is high. The updated control might benefit some applications while breaking others.

Applications that are built with Windows Forms controls do not risk being broken when you download an update for a control. The reason for this is that Windows Forms controls are local to each application, meaning that each application is bound to a particular version of the control. If an updated control becomes available on a system, the application does not automatically pick it up. Instead, it continues to use the version of the control that it was originally built against. If you want the application to pick up the latest version of the control automatically, you can change the policy for the application to cause it to do so. You can do this on an application-by-application basis to ensure that applications that will benefit from the updated control will use it, whereas ones that won t benefit or that risk being broken continue to use the version of the control known to work with the application.

This change means that if you have an application based purely on Windows Forms controls that you have built, tested, and deployed, you can count on the application to run on a machine without disruption. No future control updates installed on the machine can affect it. The application will continue to run with the controls that it was tested against.

Simpler Deployment

When you deploy an application based entirely on Windows Forms controls and .NET components, you will find that fewer files are needed. If your application contains ActiveX controls, more files must be deployed, since an extra DLL is generated for each ActiveX control. The extra DLL is the COM interop assembly needed to facilitate the communication between Windows Forms and the ActiveX control.

If you are using Windows Forms controls that are equivalent to the ActiveX controls provided by Visual Basic 6 in your application such as RichText, ProgressBar, StatusBar, Toolbar, TreeView, and ListView the controls are provided as part of the Windows Forms assembly. No additional DLLs are required when you use these controls. If you are using controls provided by an outside vendor, you can deploy the control by copying the control assembly (DLL) to your application directory the directory where your EXE file lives. No registration of the Windows Forms control is required.