2009-11-04 15 views
5

Heredé un proyecto VB6 que tiene un formulario con controles VB (etiqueta, etc.) y controles comunes de Windows (TreeView, ImageList, etc.), que parece un candidato ideal para un control de usuario.VB6 ¿ocx creado en .NET WinForm?

Mencioné a un colega la posibilidad de compilarlo como un control ocx ActiveX para ser utilizado en un proyecto .NET WinForms. Estaban ligeramente horrorizados por la experiencia previa de usar una ocx VB en un proyecto de C++: todo estuvo bien durante la fase de creación de prototipos, pero hubo problemas de sincronización y actualización cuando se usaron de verdad (muchos controles en un diálogo, tabular entre controles, desactivar y luego activar el diálogo, etc.).

¿Alguien tiene alguna experiencia de usar un ocx creado por VB6 en .NET Windows Form? ¿Puedo esperar problemas sutiles o juegan bien juntos?

+0

+1 Interesante pregunta. Será particularmente interesante ver las respuestas que relatan la experiencia real de usar un OCX que han escrito en VB6 en un formulario .NET. – MarkJ

+0

Me pregunto si hay diferencias dependiendo de qué versión de .NET estás usando. –

Respuesta

2

Me encantaría ir de .NET -> VB 6.0 usando el Interop Forms Toolkit 2.0 de Microsoft para este propósito. He hecho esto muchas veces. Ir por el otro lado podría ser doloroso.

Lo que le preocupa a su colega es muy real. El problema que entra es qué control se centra en qué momento y cómo ciertos pensamientos se manejan bajo el capó. Un buen ejemplo de esto es tabular a través de los controles.

Considere que tiene un formulario .NET con algunos controles .NET y un VB 6 Active X. Este ActiveX también tendrá controles en él. Ahora, al desplazarse por el formulario .NET, cuando llegue al ActiveX, entonces espera para desplazarse por todos los controles en ActiveX, pero no es así. Deberás tabular todo el control ActiveX a la vez. Esto es un problema.

Ahora, si va al revés, .NET dentro de VB 6.0, debe tener en cuenta este comportamiento en el código. Este CodeProject article, tiene una excelente clase llamada ActiveXHelpers que hace precisamente eso. Pero, básicamente, se trata de manejar manualmente el evento KeyPressed, verificar una pestaña o shift + tabulación, y enfocar manualmente el control siguiente/anterior.

Ahora en su situación tendría que modificar el código de VB 6 para comportarse así. Lo más probable es que sea menos esfuerzo reescribir el control en .NET. Nunca he experimentado problemas y me han refrescado, pero como dije, solo he ido .NET -> VB, no al revés. De cualquier forma, es probable que haya mucho dolor involucrado y lo más probable es que tenga otros problemas, como el hundimiento de eventos y la diferencia entre el diseño y el tiempo de ejecución en VB.

1

Lamentablemente solo tengo media respuesta. Usamos un solo control VB6 OCX en un formulario .NET y funciona sin problemas. No se usa con ningún otro control .NET u OCX en ese formulario. Proporciona una vista especializada en una base de datos.

0

En nuestro paquete de software tenemos bastante combinación de VB6 y .NET. Usamos varios controles ActiveX creados por VB6 en aplicaciones VB.NET y C#. En su mayor parte, funciona sorprendentemente bien.

El mayor dolor de cabeza que tenemos es que cuando cambia la versión de los controles VB6, tenemos que volver a agregar las referencias en los proyectos .NET. Parece que las bibliotecas de interconexión .NET están ligadas a una versión específica del control y no pueden regenerar la interoperabilidad para una nueva versión sin eliminar las interoperabilidades del proyecto y volver a crearlas. Un poco de dolor, pero he encontrado formas de hacerlo, así que no tengo que eliminar y volver a crear todas las instancias de los controles.

Cuestiones relacionadas