The Power Packs are available as free downloads. In addition to the downloads page, the Visual Basic team also maintains a suggestion page directly related to features that you, as a Visual Basic developer, would like to see. This page also includes links to the existing Power Packs and is a great place to start when looking for more information on the Power Packs: https://connect.microsoft.com/vbasic.

The current download for the Interop Forms Toolkit 2.0 can be found at www.microsoft.com/downloads/details.aspx?familyid=934de3c5-dc85-4065-9327-96801e57b81d&displaylang=en.

The current download for the Visual Basic 2005 Power Packs 2.0 can be found at www.microsoft.com/downloads/details.aspx?familyid=92faa81e-e9c1-432c-8c29-813493a04ecd&displaylang=en.

Keep in mind that two separate download packages are needed to collect all of the assorted tools available to Visual Basic developers, and that both packages are currently on version 2.0.

Additional forums are available to discuss issues or ask questions regarding use of the tools. The Interop Forms Toolkit forum is at http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=879&SiteID=1

The forum for the Power Packs 2.0 package is at: http://forums.microsoft.com/MSDN/ShowForum.aspx?ForumID=903&SiteID=1.

Select the project type shown in Figure B-2 and rename the solution ProVB_AppB_InteropForm. Click OK to generate your source project files. The resulting project opens, and you can open and edit your new Windows Form. However, note that what you are creating, while it supports the Form Designer, isn't a standalone executable. If you open your project properties, you'll find that your project will build as a DLL, not a standalone executable.

Another thing to note is that as part of the generation of your project, a file named InteropInfo.vb is created. This file takes settings that might otherwise exist in your AssemblyInfo.vb file and places them here so they are a bit more apparent. The first line references the standard COM Interop classes and turns these settings off. This is important because you won't be using traditional COM Interop; you've added a new Interop class specifically for this purpose. By moving this setting into a separate file, if you do accidentally cause the AssemblyInfo.vb file to be regenerated by Visual Studio, you'll get a compile error. This is good because you can quickly and easily delete the newly duplicated line from AssemblyInfo.vb and not wonder why your project suddenly isn't working correctly. Compile errors are always better then runtime errors. The other item in this file is a declaration that extends the My namespace to include the Interop toolbox. In general, you shouldn't make any changes to this file, but now you know what it's doing.

Opening the InteropForm1.vb, you have a typical design surface for a form, on which you can add controls. Behind the scenes is an InteropForm1.vb that contains the following default code:

Imports Microsoft.InteropFormTools

<InteropForm()> _
Public Class InteropForm1

End Class

As you can see, the default class definition has been decorated with an attribute indicating that this class should be considered an InteropForm. This enables the postprocessor that is used to generate your COM wrappings to recognize which type of wrapping should be applied to this class.

For now, however, go to the Form Designer, and because this is a truly simple demo, drag a label and a TextBox control onto the display. Within the code, create the four other types of interface members you'll want in your production code: an initializer, a property, a method, and an event (in that order). The following code is placed within your class definition:

Public Sub New()
    ' This call is required by the Windows Form Designer.
    InitializeComponent()

    ' Add any initialization after the InitializeComponent() call.
    End Sub

    <InteropFormInitializer()> _
    Public Sub New(ByVal label As String)
        Me.New()
        Label1.Text = label

    End Sub

    <InteropFormProperty()> _
    Public Property TextBoxText() As String
        Get
            Return TextBox1.Text
        End Get
        Set(ByVal value As String)
            TextBox1.Text = value
        End Set
    End Property

    <InteropFormMethod()> _
    Public Sub ChangeLabel(ByVal lbl As String)
        Label1.Text = lbl
        RaiseEvent CustomEvent(lbl)
    End Sub

    <InteropFormEvent()> _
    Public Event CustomEvent As CustomEventSig

    'Declare handler signature...
    Public Delegate Sub CustomEventSig(ByVal lblText As String)

For the initialization code you'll note that first a default New constructor, is created. When you define the default New constructor, it adds the call to InitializeComponent, which handles the creation of your controls within the form. Thus, when the object is initialized, you will be able to reference the controls you have placed on the form.

The next step is to create a parameterized constructor so that you can quite literally pass a parameter as part of the initialization process. Note that similar to the class itself, the exposed initialization method has an attribute on the method. Each type of class member that is to be exposed gets an attribute matching the type of that method. Thus, for the New method, the type of the attribute is InteropFormInitializer. For this simple example, the parameterized New(ByVal label As String) simply changes the text associated with the label. Finally, although this class is defined in .NET syntax, COM and VB6 don't allow parameterized New statements. Thus, when you go to reference this parameterized initializer, you'll find that the method name is in fact Initialize.

Next, the code defines and exposes a public property. In this case, to help simplify the code, there isn't a private member variable to hold the value; this provides an easy way for the code that creates this form to set and retrieve the value of the text box. Similarly, there is a method to allow the calling code to update the label shown on the form. Note that it has also been attributed, and after you update the label for demonstration purposes, it raises the custom event that is defined next.

That event, called CustomEvent, is defined with an attribute, but the event that is defined must also define the signature or definition of its handlers. In this case, the Delegate CustomEventSig handles a single parameter. This .NET code, as noted, provides a basic example of each of the primary types of Interop you'll want to carry out. The next step is to generate your Interop methods.

One of the key differences between an InteropForms project and an Interop User Control project is this step. Only the InteropForms project requires the generation of custom COM wrappers. To do this, access the Tools menu and select Generate InteropForm Wrapper Classes. There is no user interface; instead, the generation process will create a new directory in your project containing the InteropForm1.wrapper.vb class, as shown in Figure B-3.

Figure B.3. Figure B-3

At this point, your application is ready to be called from VB6. If you follow best practices, you'll have the VB6 integrated development environment (IDE) installed on the machine with Visual Studio 2008. In that scenario, you can immediately go to your VB6 project and reference the necessary DLLs, both the Interop Forms Toolkit DLL and your custom DLL. Otherwise, you'll need to get ready for deployment now instead of later.

To deploy your Interop Forms project, you need a traditional MSI installation. Creating a setup project is covered in Chapter 24, so the details of creating your setup project aren't repeated here. However, note a couple of special steps. In order for your new Interop Forms project to work on the client, the client needs both the .NET Framework 2.0 redistributable and the second MSI you downloaded earlier in this chapter (shown in Figure B-1), the microsoft.interopformsredist.msi. If you are using Visual Studio 2005 to create your installation package, then you can add these items as prerequisites for installing your DLL via the user interface.

The recommendation is to create a simple setup project in Visual Studio 2005 for installing your Interop Forms project and the associated prerequisites and have this run in advance of whatever legacy installation project you have. To extend an existing MSI, you need to carry out the appropriate steps for the tool generating your MSI, a subject beyond the scope of this appendix.

When you first start planning to work with the toolkit, you might try to keep the VB6 IDE on a separate machine from your primary development machine. However, this leads to two issues. First, in order to work with the Interop Forms tools on your VB6 machine, you need to install the tools package a second time. That's a minor issue. Second, because Visual Basic 6.0 doesn't know how to step into .NET applications, if you want to debug the Interop Form you created in .NET, you have a problem. The solution to this, of course, is to run both development environments on the same machine.

Alternatively, you can try to create a simple Windows Forms EXE that will call and initiate your Interop Forms project from within .NET. The debugging isn't perfect because, of course, you aren't actually calling your code across the correct interface, but it should enable you to find most pure .NET coding issues. You can also leverage the Debug and Trace classes, but you won't have any interactive breakpoints in that scenario.

This still leaves unresolved the issue that you can't just open Visual Studio 2008 and expect the VB6 IDE to call it when you are in debug mode. Therefore, this section briefly discusses debugging Interop Forms Toolkit projects when you are running your VB6 application.

Once you have compiled your .NET application, you have a DLL. This DLL is then exposed to your VB6 development environment and added as another COM component in your VB6 application. However, when you debug, you can't step into this DLL from Visual Basic. Presuming you have started your Visual Basic 6.0 project so that its process is now running, your next step is to open Visual Studio 2008 and open your Interop Forms project. It is hoped that you have set typical breakpoints in your source code and might even add new breakpoints.

Next, go to the Tools menu and select the Attach to Process menu item. At this point, you get a dialog containing a list of running processes. Locate the "Visual Basic 6.0.exe" process. Once you have found this process, which represents the running application in VB6, attach to this process.

At this point, you can work with your running application, and when the call is made into your .NET code, Visual Studio 2008 detects the call into the DLL and stops you on your breakpoint. In order for Visual Studio 2008 to detect the DLL call, you must be calling the same copy of your DLL that your Interop Forms project references. In other words, you can't just copy it off to some other location on your local machine for installation.

Overall, the development process in VB6 is simple. Once you have either built your project or deployed it to the machine on which you have the VB IDE, you'll need to add references to both the Microsoft Interop Form Toolkit library and your custom DLL. Keep in mind that both of the DLLs must be registered on your VB6 IDE machine for them to be visible. If you are building on the same machine, they are automatically visible. Once you have added references for these libraries, you can create a new instance of your Interop Form's Form class and call the standard methods and any custom methods you've exposed on that form.

The one key point to remember, which was mentioned earlier but bears repeating, is that if you have created a custom constructor, in order to use it, you will call an Initialize method on your Interop Form class.

As noted earlier in the book during the discussion of the WPF Interop controls, the Interop control packages aren't perfect. Each has certain limitations that reduce their desirability for the long term. To resolve this, keep track of how much of various branches you have already converted. There will be a point where it is time to convert a larger section so that you can reduce the number of different Interop DLLs that you are using.

Along these lines, note that you can't put an Interop Form and an Interop User Control into the same project. Each of these items needs its own DLL, and, in fact, you should consider it best practice to only expose the DLL for a single form or control. Similarly, don't plan on calling a VB6 form from within your Interop Form. The Interop logic was written to enable you to call .NET from VB6.

In terms of interfaces, the Interop layer was designed to support only a minimum number of interface types. In particular, the String, Integer, and Boolean types should be at the core of what you expect to pass in terms of data. In theory, the Object type is supported, which enables you to pass custom data, so you could pass a Recordset from .NET to VB6 or vice versa; of course, VB6 doesn't know about a Dataset object, so you need to reference VB6 types as the generic object. In general, the best practice is to keep your interfaces as simple as possible.

When you start the VB6 IDE with your project, it attaches to your DLL. Normally this isn't an issue until you first run your VB6 application. At this point, you can't rebuild your Interop project. The Interop project is, in fact, referenced and therefore locked by VB6. If you need to rebuild your Interop project, you need to first shut down the VB6 development environment so that your code will correctly reference your latest build. As noted previously, debugging your Interop project from VB6 isn't the most productive set of steps.

If you change any of the method attributes, you need to regenerate the Interop wrapper classes that you generated in the last step of creating your Interop Forms project. Moreover, although it wasn't covered, you can raise errors from .NET into VB6. To do this, you want to leverage the following method call on the custom My namespace that was defined as part of your Interop Form:

My.InteropToolbox.EventMessenger.RaiseApplicationEvent("CRITICAL_ERROR", _ "Error
Detail.")

The other runtime issue that you may encounter is that certain internal events to your .NET application will not be triggered in the same fashion that they were in VB6. Under VB6, for example, when you referenced a property on a Form class, this triggered the Load event on that class. Under .NET, the Load event is not fired until the form is being displayed, so you need to recognize the impact on any code that you previously set to run on the Load event.

The remaining issue is related to the VB6 IDE. The IDE and VB6 don't really recognize that if you have started a .NET DLL, there are other in-memory classes to release. For a deployed application, this isn't an issue because when the application is closed, all of the memory associated with the process is automatically released. When you are debugging in VB6, however, the core process is associated with the IDE, not your application. As a result, the resources are not released between debugging cycles. To ensure that they are released, you can explicitly instantiate a series of code modifications contained in the Interop help files and release the .NET resources associated with your application. The recommendation is to implement these calls only after your references with the Interop tools are functioning correctly.