2009-11-04 13 views
5

J'ai hérité d'un projet VB6 qui a un formulaire avec des contrôles VB (Label, etc) et des contrôles Windows communs (Treeview, ImageList, etc), qui ressemble à un candidat idéal pour un contrôle userc.OCB écrit par VB6 sur un .NET WinForm?

je l'ai mentionné à un collègue la possibilité de compiler comme un contrôle ActiveX OCX à utiliser dans un projet .NET WinForms. Ils étaient légèrement horrifiés à cause de l'expérience précédente d'utiliser un ocx VB dans un projet C++: tout allait bien pendant la phase de prototypage mais il y avait des problèmes de timing et d'actualisation en réel (beaucoup de contrôles sur un dialogue, tabulation entre contrôles le dialogue, etc.).

Est-ce que quelqu'un a déjà utilisé un ocx écrit par VB6 sur un formulaire Windows .NET? Puis-je m'attendre à des problèmes subtils ou jouent-ils bien ensemble?

+0

+1 Question intéressante. Il sera particulièrement intéressant de voir des réponses relatant l'expérience réelle de l'utilisation d'un OCX qu'ils ont écrit en VB6 sur un formulaire .NET. – MarkJ

+0

Je me demande s'il existe des différences selon la version de .NET que vous utilisez. –

Répondre

2

Je voudrais aller très heureux de .NET -> VB 6.0 en utilisant la Interop Forms Toolkit 2.0 de Microsoft pour exactement cet effet. Je l'ai fait plusieurs fois. Aller dans l'autre sens pourrait être douloureux.

Ce qui préoccupe votre collègue est très réel. Le problème qui se pose est de savoir quel contrôle est ciblé à quel moment et comment certaines personnes sont traitées sous le capot. Un excellent exemple de ceci est la tabulation à travers les contrôles.

Considérez que vous avez une forme .NET avec des contrôles .NET et une VB 6 active X. Cet ActiveX aurait également des contrôles en elle. Maintenant que vous onglet dans votre formulaire .NET, quand vous arrivez à l'onglet ActiveX alors vous attendre à travers tous les contrôles dans ActiveX, mais vous ne faites pas! Vous allez tabuler sur l'ensemble du contrôle ActiveX à la fois. C'est un problème.

Maintenant, si vous allez dans l'autre sens, .NET dans Visual Basic 6.0, vous devez répondre pour le comportement dans votre code. Ce CodeProject article, a une excellente classe appelée ActiveXHelpers qui fait exactement cela. Mais fondamentalement, il s'agit de gérer manuellement l'événement KeyPressed, en vérifiant un onglet ou shift + tab, et la mise au point manuellement le contrôle suivant/précédent.

Maintenant, dans votre situation, vous devez modifier le code VB 6 pour qu'il se comporte comme ceci. Il sera probablement moins d'effort pour réécrire le contrôle dans .NET. Je n'ai jamais connu et rafraîchi les problèmes, mais comme je l'ai dit, je suis seulement allé .NET -> VB pas l'inverse. D'une manière ou d'une autre, il y aura probablement beaucoup de douleur et vous aurez probablement d'autres problèmes, comme le fait de couler des événements et de faire la différence entre la conception et l'exécution dans VB.

1

Malheureusement, je n'ai qu'une demi-réponse. Nous utilisons un seul contrôle VB6 OCX sur un formulaire .NET et cela fonctionne sans aucun problème. Il n'est utilisé avec aucun autre contrôle .NET ou OCX sur ce formulaire. Il fournit une vue spécialisée dans une base de données.

0

Dans notre suite logicielle, nous avons un mélange de VB6 et .NET. Nous utilisons un certain nombre de contrôles ActiveX créés par VB6 dans les applications VB.NET et C#. Pour la plupart, cela fonctionne étonnamment bien.

Le plus grand mal de tête que nous avons est que lorsque la version des contrôles VB6 changer, nous devons ajouter à nouveau les références dans les projets .NET. Il semble que les bibliothèques .NET interop sont liées à une version spécifique du contrôle et ne peuvent pas régénérer l'interop pour une nouvelle version sans supprimer l'interop du projet et le recréer. Un peu pénible, mais j'ai trouvé des façons de le faire pour ne pas avoir à supprimer et recréer toutes les instances des contrôles.