VB6 authored ocx on a .NET WinForm?

Question

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?

Answer 1

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.