When should I use an Interop UserControl vs an InteropForm?
Both InteropForms and Interop UserControls allow you to put .NET content in your Visual Basic 6.0 application, but they do so in different ways. The advantage of Interop UserControls is that you can extend your Visual Basic 6.0 applications within the same form. InteropForms work well when you want to add an entirely new screen to your application, while UserControls are better suited to adding .NET content to an existing form.
UserControls are also the best solution for Visual Basic 6.0 MDI forms — you can't use an InteropForm as an MDI child, but you can create an Interop UserControl and add it to an MDI child.
Some key differences to keep in mind:
- InteropForms use an attribute-based approach. To expose properties, methods and events to your Visual Basic 6.0 application, use the <InteropProperty> attribute and click Tools->Generate InteropForm Wrapper Classes. With Interop UserControls, you simply need to make the members Public and then build in order for Visual Basic 6.0 to see them; there is no need to click Tools->Generate InteropForm Wrapper Classes.
- Interop UserControls can only be used in the Visual Basic 6.0 Interop UserControl Library template, and InteropForms can only be used in the Visual Basic 6.0 InteropForm Library template. If you want to use both in a Visual Basic 6.0 application, you’ll need to build a solution that contains one project for Forms and one project for UserControls.
The events aren’t firing on my Interop UserControl, what do I do?
The mechanism for handling events on UserControls is different from Forms. For more information, see How To: Handle Interop UserControl Events.
Can I create control arrays of Interop UserControls?
On a machine that has the .NET Framework 3.5 installed (even if you’re using the 2.0 framework), control arrays will work. The functionality to support this was not present in the .NET Framework 2.0. As a workaround you can either create multiple controls or use a VBControlExtender to dynamically add Interop UserControls to your form.
When building my project, I get the following error: “Unable to copy file "obj\Release\MyUserControl.dll" to "bin\Release\MyUserControl.dll"
The process cannot access the file 'bin\Release\MyUserControl.dll' because it is being used by another process. This usually means that the DLL is in use by Visual Basic 6.0. In order to rebuild the UserControl, the Visual Basic 6.0 project that uses it must be closed. What you can do is set your Build Action in .NET to automatically load the Visual Basic 6.0 project, making it more convenient to work with the two projects at once. For more information on setting this up, see How To: Debug a Hybrid Application.
How do I handle Exceptions raised from the .NET side?
In order to use Visual Basic 6.0-style error handling to handle .NET exceptions, you can use the standard On Error syntax around any calls to Interop components (for example a public method on an Interop UserControl).
This approach works well when the .NET code that caused the exception was explicitly called by Visual Basic 6.0 (For example, when a Visual Basic 6.0 method is on the call stack). However, there may be situations however where an exception is raised on the .NET side due to a user’s action (For example, clicking a button on an Interop UserControl). In this case throwing an exception directly will result in the .NET Unhandled Exception dialog (since the code that invoked the exception does not have Visual Basic 6.0 code in the underlying call stack).
For this situation it’s important to ensure that all your .NET code has Try/Catch/Finally blocks around it. When you catch an exception that you want to notify Visual Basic 6.0 about, use the RaiseApplicationEvent method on the EventMessenger class to notify Visual Basic 6.0 about the problem. For more information, see How To: Raise an Application-Level Event.
To summarize, if the exception occurs in .NET code that was explicitly invoked by Visual Basic 6.0 code, you can use On Error on the Visual Basic 6.0 side and the Throw statement on the .NET side. If the exception occurs in .NET code that was explicitly invoked by the user, you must use the RaiseApplicationEvent method and then handle the resulting event on the Visual Basic 6.0 side.