6
votes

I've inherited a VB6 project that has a Form with VB controls (Label, etc) and Windows Common controls (Treeview, ImageList, etc), which looks like an ideal candidate for a usercontrol.

I mentioned to a colleague the possibility of compiling it as an ocx ActiveX control to be used in a .NET WinForms project. They were slightly horrified because of previous experience of using a VB ocx in a C++ project: everything was fine during the prototyping phase but there were timing and refresh problems when used for real (many controls on a dialog, tabbing between controls, deactivating then activating the dialog, etc).

Does anyone have any experience of using a VB6 authored ocx on a .NET Windows Form? Can I expect subtle problems or do they play nice together?

3
+1 Interesting question. It will be particularly interesting to see answers relating actual experience of using an OCX they've written in VB6 on a .NET form.MarkJ
I wonder if there are differences depending upon which version of .NET you're using.David T. Macknet

3 Answers

2
votes

I would quite happily go from .NET -> VB 6.0 using the Interop Forms Toolkit 2.0 from Microsoft for exactly this purpose. I have done this many times. Going the other way could be painful.

What your colleague is concerned about is very real. The problem that comes in is which control is focused at which time and how certain thinks get handled under the hood. A prime example of this is tabbing across controls.

Consider that you have a .NET form with some .NET controls and a VB 6 Active X. This ActiveX would also have controls in it. Now as you tab across your .NET form, when you get to the ActiveX you would then expect to tab across all the controls in the ActiveX, but you don't! You will tab over the whole ActiveX control at once. This is a problem.

Now if you are going the other way around, .NET inside VB 6.0, you have to cater for behavior this in code. This CodeProject article, has an excellent class called ActiveXHelpers that does just that. But basically it comes down to manually handling the KeyPressed event, checking for a tab or shift+tab, and the focusing the next/previous control manually.

Now in your situation you'd need to modify the VB 6 code to behave like this. It'll most likely be less effort to rewrite the control in .NET. I've never experienced and refreshing problems, but like I said I've only gone .NET -> VB not the other way around. Either way there is likely to be lot of pain involved and you'll most likely have other issues, such as sinking events and telling the difference between design and runtime in VB.

1
votes

Unfortunately I only have half an answer. We use a single VB6 OCX control on a .NET Form and it works without any issues. It is not used with any other .NET or OCX control on that form. It provides a specialized view into a database.

1
votes

In our software suite we have quite the mix of VB6 and .NET. We use a number of VB6 authored ActiveX controls in both VB.NET and C# applications. For the most part, it works surprisingly well.

The biggest headache we have is that when the version of the VB6 controls change, we have to re-add the references in the .NET projects. It seems .NET interop libraries are tied to a specific version of the control and it can't regenerate the interop for a new version without removing the interops from the project and recreating them. A bit of a pain, but I've found ways of doing it so I don't have to remove and recreate all instances of the controls.