Descripción general
En este artículo se ofrecen algunas recomendaciones destinadas a los desarrolladores que utilizan Microsoft® Visual Basic® y que desean actualizar sus aplicaciones a Microsoft Visual Basic.NET.
Visual Basic.NET permite abrir y actualizar proyectos de Visual Basic 6.0. No obstante, en la mayoría de los casos, se deberán realizar varias modificaciones en los proyectos actualizados a las tecnologías de Visual Basic.NET. El objetivo de este artículo es facilitar las líneas maestras para el diseño e implementación de los proyectos actuales de Visual Basic de forma que se minimice el número de cambios necesarios al actualizarlos a Visual Basic.NET. Aunque a lo largo de este artículo se utilizan determinadas construcciones del lenguaje Visual Basic.NET, no pretende ser una referencia al mismo.
Nota Visual Basic.NET aún se encuentra en desarrollo, por lo que es probable que se introduzcan algunos cambios en cuanto a compatibilidad antes del lanzamiento del producto. El hecho de seguir las directrices de este artículo no garantiza que no se deban realizar algunos cambios en el código. Las directrices pretenden únicamente reducir el trabajo necesario para la conversión.
¿Qué es Visual Basic.NET?
Visual Basic.NET es la versión siguiente de Visual Basic, en la que Microsoft no sólo ha incorporado nuevas características a Visual Basic 6.0, sino que ha realizado un nuevo proyecto de ingeniería para el producto a fin de facilitar más que nunca el desarrollo de aplicaciones distribuidas como sistemas Web y sistemas empresariales de n niveles. Visual Basic.NET dispone de dos nuevos paquetes de formularios (los formularios de Windows y los formularios Web), una nueva versión de ADO para obtener acceso a orígenes de datos desconectados y un lenguaje simplificado en el que se eliminan las palabras clave heredadas, se mejora la seguridad de los tipos y se exponen las construcciones de bajo nivel que requieren los desarrolladores avanzados.
Estas características abren nuevas vías para el desarrollador de Visual Basic, ya que, con los formularios Web y ADO.NET, podrá desarrollar rápidamente sitios Web escalables. La herencia permite que el lenguaje Visual Basic sea compatible con la programación orientada a objetos. Por su parte, los formularios de Windows ofrecen, de forma nativa, gran accesibilidad y son compatibles con la herencia visual. Asimismo, la distribución de las aplicaciones resulta ahora tan simple como copiar archivos ejecutables y componentes de un directorio en otro.
Visual Basic.NET se encuentra totalmente integrado con el resto de los lenguajes de Microsoft Visual Studio.NET. No sólo permite desarrollar componentes de aplicaciones en distintos lenguajes de programación, sino que también permite heredar las clases escritas en otros lenguajes utilizando la herencia de varios lenguajes. Con el depurador unificado, ahora se pueden depurar aplicaciones de distintos lenguajes, aunque se ejecuten en equipos locales o remotos. Por último, independientemente del lenguaje utilizado, Microsoft .NET Framework ofrece una amplia gama de API para Microsoft Windows® e Internet.
¿Por qué Visual Basic.NET no es compatible al 100%?
Se barajaron dos opciones a la hora de diseñar Visual Basic.NET: la retroalimentación de la base de códigos existente para su ejecución sobre .NET Framework o la creación desde el principio, aprovechando al máximo la plataforma. Para poder ofrecer las características más solicitadas por los clientes (p. ej., la herencia o el subprocesamiento) y un acceso completo e ilimitado a la plataforma, así como garantizar que Visual Basic no perdiese el tren de la nueva generación de aplicaciones Web, lo idóneo era crear la nueva plataforma desde el principio.
Se podían haber agregado al código existente varias de las nuevas características de los formularios de Windows, como nuevos controles o propiedades. No obstante, se habrían perdido con ello otras características muy importantes inherentes a los formularios de Windows, como la seguridad y la herencia visual.
Uno de los principales objetivos era garantizar la completa interoperabilidad del código Visual Basic con el código escrito en otros lenguajes, como Microsoft Visual C#™ o Microsoft Visual C++®, y permitir que el desarrollador de Visual Basic pudiera aprovechar fácilmente la eficacia de .NET Framework, sin tener que recurrir a las típicas soluciones temporales de programación para hacer funcionar las API de Windows. Visual Basic dispone de los mismos tipos de variables, matrices, tipos definidos por el usuario, clases e interfaces de Visual C++ o cualquier otro lenguaje destinado al tiempo de ejecución en lenguaje común. No obstante, era necesario eliminar varias características del lenguaje, como las cadenas de longitud fija y las matrices con límite distinto de cero.
Visual Basic es ahora un verdadero lenguaje orientado a objetos, en el que se han eliminado varias características no intuitivas e incoherentes como GoSub/Return y DefInt.
El resultado ha sido una increíble mejora de Visual Basic, la herramienta más productiva para la creación de aplicaciones basadas en Windows y que disfruta de una posición privilegiada para recibir a la nueva generación de sitios Web.
Actualización a Visual Basic.NET
Visual Basic.NET permite la transición fundamental desde el desarrollo tradicional de Windows a la creación de la nueva generación de aplicaciones Web y de n niveles. Por esta razón, será necesario actualizar el código para aprovechar al máximo las ventajas que ofrece Visual Basic.NET.
Al abrir un proyecto de Visual Basic 6.0 en Visual Basic.NET, la actualización tiene lugar automáticamente: el asistente para la actualización muestra los pasos necesarios para actualizar el producto y crea un nuevo proyecto de Visual Basic.NET (sin modificar el proyecto existente). Se trata de un proceso de sentido único, ya que el nuevo proyecto resultante de Visual Basic.NET no se podrá abrir en Visual Basic 6.0.
Una vez se ha actualizado el proyecto, el lenguaje se modifica para reflejar los cambios en la sintaxis y los formularios de Visual Basic 6.0 se convierten en formularios de Windows. En la mayoría de las ocasiones, se deberán introducir ciertos cambios en el código una vez se haya actualizado, dado que determinados objetos y características del lenguaje, o no tienen un equivalente en Visual Basic.NET, o su equivalente es tan dispar que no permite la actualización automática. Asimismo, una vez finalizado el proceso de actualización, se pueden realizar varias modificaciones en la aplicación para beneficiarse de varias de las nuevas características de Visual Basic.NET.
Por ejemplo, los formularios de Windows admiten la delimitación de control, por lo que se puede eliminar la mayor parte del antiguo código de ajuste de tamaño de los formularios de Visual Basic 6.0:
Figura 1. Compatibilidad de VB.NET con la delimitación de control
Para facilitar la realización de cambios una vez se ha actualizado el proyecto, Visual Basic.NET agrega un "informe de actualización" en el que se enumeran los posibles problemas. También se incluyen comentarios en el código actualizado indicando las instrucciones que se deberán modificar. Dado que estos comentarios aparecen como tareas pendientes en la nueva ventana de lista de tareas, se podrán ver fácilmente los cambios necesarios e ir a la instrucción de código deseada haciendo doble clic en la tarea. Cada tarea y objeto que aparece en el informe de actualización se asocia a un tema de la ayuda en línea, donde se encontrará más información sobre el cambio que se debe hacer y por qué.
Las recomendaciones que se incluyen en este artículo ayudarán a minimizar o incluso eliminar los cambios que se deben realizar en el proyecto actualizado de Visual Basic.NET. En la mayoría de los casos, las recomendaciones no son más que buenas prácticas de programación. No obstante, en el artículo también se identifican los objetos y métodos que no disponen de equivalentes y que se deben utilizar con moderación si se pretende actualizar un proyecto a Visual Basic.NET.
Uso conjunto de Visual Basic 6.0 y Visual Basic.NET
Visual Basic.NET permite actualizar los proyectos de Visual Basic 6.0. Si dispone de un proyecto en las versiones 1 a 5 de Visual Basic, se recomienda cargarlo en VB6 (seleccionando la actualización de los controles Microsoft ActiveX®), compilarlo y guardarlo antes de actualizarlo a Visual Basic.NET.
Tanto Visual Basic.NET como Visual Basic 6.0 se pueden instalar en el mismo equipo y ejecutar al mismo tiempo. Lo mismo ocurre con las aplicaciones escritas en Visual Basic.NET y Visual Basic 6.0. Los componentes escritos en Visual Basic.NET pueden interoperar con los componentes COM escritos en versiones anteriores de Visual Basic y otros lenguajes. Por ejemplo, se puede soltar un control ActiveX escrito en Visual Basic 6.0 en un formulario de Windows de Visual Basic.NET, utilizar un objeto COM de Visual Basic 6.0 de una biblioteca de clases de Visual Basic.NET o agregar una referencia a una biblioteca de Visual Basic.NET a un ejecutable de Visual Basic 6.0.
Los componentes compilados con Visual Basic.NET difieren un tanto en lo que respecta al tiempo de ejecución de los componentes compilados con Visual Basic 6.0. Al utilizar el producto por primera vez, dado que los objetos de Visual Basic.NET se liberan a través de la recolección de elementos no utilizados, cuando se destruyen los objetos explícitamente, puede que transcurra cierto tiempo antes de que se eliminen de la memoria. Asimismo, existen diferencias adicionales, como el cambio de Variant a Object, que se describe más adelante. Como resultado de todas estas diferencias, las aplicaciones de Visual Basic.NET disponen de un comportamiento en tiempo de ejecución similar, aunque no idéntico, a las aplicaciones de Visual Basic 6.0.
Asimismo, gracias a Visual Basic.NET, no es necesaria la compatibilidad binaria entre los componentes de Visual Basic.NET y Visual Basic 6.0. Los componentes ahora disponen de un sistema de versión y distribución muy sólido, en el que, para distribuir archivos, basta con copiarlos en un directorio (ya no es necesario utilizar RegSvr32) y en el que, para actualizar un componente a una nueva versión, sólo es necesario sustituir el archivo anterior por el nuevo. Lo único de lo que deberá asegurarse es de garantizar que las clases y métodos sean compatibles con la versión anterior.
Recomendaciones relativas a la arquitectura
La plataforma .NET mejora las arquitecturas anteriores, dispone de un mayor nivel de escalabilidad y admite un mayor número de aplicaciones distribuidas gracias a un acceso a datos desconectado, al transporte de mensajes basado en HTTP y a un sistema de distribución basado en la copia de archivos (donde ya no es necesario el registro de componentes). Para obtener el máximo rendimiento de estas características, se recomienda diseñar las aplicaciones con una arquitectura similar a la que se utiliza en Visual Basic.NET.
Aplicaciones basadas en exploradores
Visual Basic 6.0 y Microsoft Visual Studio® 6.0 ofrecían varias tecnologías para la creación de aplicaciones de Internet e intranet basadas en exploradores:
Clases de Web
Proyectos DHTML
Documentos ActiveX
Páginas Active Server (ASP)
Visual Basic.NET introduce ASP.NET, un versión mejorada de ASP y agrega formularios Web a su arquitectura, es decir, páginas HTML con eventos de Visual Basic. La arquitectura está basada en el servidor.
A continuación se muestra una serie de recomendaciones y sugerencias relativas a la arquitectura para el desarrollo de aplicaciones Visual Basic 6.0 basadas en exploradores que permitirán la migración perfecta a proyectos de Visual Basic.NET:
Se recomienda utilizar las directrices de la arquitectura Microsoft de varios niveles para crear las aplicaciones, crear la interfaz con ASP y utilizar los objetos COM de Visual Basic 6.0 o Visual C++ 6.0 para la lógica empresarial. Visual Basic.NET es totalmente compatible con ASP, por lo que la aplicación desarrollada se puede extender utilizando ASP, ASP.NET y formularios Web. Los objetos empresariales de Visual Basic 6.0 y Visual C++ 6.0 se pueden utilizar como tales o actualizarlos a Visual Studio.NET.
Las aplicaciones DHTML contienen páginas DHTML y varias DLL del lado del cliente. Estas aplicaciones no se pueden actualizar automáticamente a Visual Basic.NET. Se recomienda dejarlas en Visual Basic 6.0.
Visual Basic.NET no es compatible con los documentos ActiveX y, al igual que los proyectos DHTML, no se pueden actualizar automáticamente. Se recomienda dejar las aplicaciones de los documentos ActiveX en Visual Basic 6.0 o, donde sea posible, sustituir los documentos ActiveX por controles de usuario.
Los documentos ActiveX de Visual Basic 6.0 y las aplicaciones DHTML pueden interoperar con las tecnologías de Visual Basic.NET. Por ejemplo, el usuario se puede desplazar de un formulario Web de Visual Basic.NET a una página DHTML de Visual Basic 6.0 y viceversa.
En Visual Basic.NET desaparecen las clases Web. Las aplicaciones que cuentan con clases Web se actualizarán a ASP.NET, sin embargo, una vez se haya realizado la actualización, será necesario realizar ciertas modificaciones. Las aplicaciones Web existentes pueden interoperar con los formularios Web de Visual Basic.NET y las aplicaciones ASP, aunque, en los nuevos proyectos, se recomienda el uso de la plataforma Windows DNA de ASP con los objetos empresariales de Visual Basic 6.0.
Para obtener más información sobre la creación de aplicaciones con la arquitectura Microsoft de varios niveles, consulte
Microsoft Windows DNA (en inglés).
Proyectos cliente/servidor
Visual Basic 6.0 ofrece varias tecnologías para la creación de aplicaciones cliente/servidor:
Formularios de Visual Basic
Objetos de nivel medio Microsoft Transaction Server (MTS)/COM+
Controles de usuario
Visual Basic.NET cuenta con un nuevo paquete de formularios, los formularios de Windows, que disponen de un modelo de objetos diferente, aunque compatible, al de los formularios de Visual Basic 6.0. Al actualizar un proyecto, los formularios de Visual Basic se convierten en formularios de Windows.
Visual Basic.NET ofrece una mayor compatibilidad para desarrollar componentes de servicios de componentes COM+ y MTS de nivel medio. El uso del depurador unificado permite ir de una aplicación cliente a un componente MTS/COM+ y viceversa. Asimismo, el depurador permite desplazarse por los distintos componentes MTS/COM+ de Visual Basic 6.0 (siempre que se encuentren compilados en código nativo, con información de depuración simbólica y sin optimizaciones).
Visual Basic.NET también introduce un nuevo componente de nivel medio, los Servicios Web. Estos servicios se alojan en ASP.NET y utilizan el transporte HTTP que permite que una solicitud de método atraviese un servidor de seguridad. Asimismo, estos servicios pasan y devuelven datos utilizando el XML estándar del sector, permitiendo que otros lenguajes y plataformas tengan acceso a su funcionalidad. Aunque no son compatibles con las transacciones MTS, puede que se desee cambiar los componentes MTS/COM+ por Servicios Web en aquellos casos en los que no sean necesarias las transacciones distribuidas, pero en los que se desea interoperar con otras plataformas. Aunque no existe un método automático para realizar esta operación, la tarea es muy sencilla y se puede realizar en unos minutos, arrastrando y soltando una vez se haya actualizado el proyecto a Visual Basic.NET.
Cuando se actualiza el proyecto, los controles de usuario se actualizan a los controles de Windows. No obstante, no se actualizará la configuración de las etiquetas de las propiedades personalizadas ni las asignaciones de teclas de aceleración.
Aplicaciones de un solo nivel
Visual Basic 6.0 permitía crear varios tipos de aplicaciones de un solo nivel:
Aplicaciones de bases de datos de un nivel
Complementos de Visual Basic
Juegos y programas de utilidad
La aplicación Visual Basic que almacena los datos en una base de datos de Microsoft Access se encarga de tipificar las aplicaciones de bases de datos de un solo nivel. Estas aplicaciones se pueden actualizar a Visual Basic.NET, aunque con ciertas limitaciones (consulte la sección de datos de este artículo).
Ahora que el IDE de Visual Basic.NET está completamente integrado en el IDE de Visual Studio.NET, Visual Basic.NET dispone de un nuevo modelo de extensibilidad de idioma neutral. Los complementos de Visual Basic.NET son ahora complementos de Visual Studio.NET y se pueden automatizar y agregar características a cualquier lenguaje de Visual Studio.NET. Por ejemplo, se puede escribir un complemento de Visual Basic.NET que cambie el color de un formulario Visual C# de Windows o que agregue comentarios a una clase de Visual Basic. Para proporcionar esta funcionalidad, Visual Basic.NET ha desechado el antiguo modelo de extensibilidad, por lo que es necesario modificar los objetos de extensibilidad de la aplicación para sacar el máximo partido de las nuevas características.
Un gran número de aplicaciones pertenecen a la categoría de programas de utilidad. La actualización de las aplicaciones de utilidad que manipulan archivos, la configuración del registro, etc., a menudo no requiere cambios adicionales. Una vez se ha llevado a cabo la actualización, se dispondrá de multitud de nuevas características, como el control de excepciones en el lenguaje para capturar los errores en el sistema de archivos y el uso de las clases de registro de .NET Framework para manipular el registro. Es necesario tener en cuenta que las aplicaciones cuyo funcionamiento dependa de determinadas características específicas de Visual Basic 6.0, como los videojuegos, probablemente se deban modificar en cierta medida, ya que Visual Basic.NET dispone de varias características de rendimiento. Para proporcionar la compatibilidad con los videojuegos en Visual Basic.NET, se puede utilizar Microsoft DirectX® 7 o la nueva versión de GDI. GDI+ introduce un gran número de nuevas características, entre las que se incluyen la combinación alfa para los antiguos gráficos en 2D, el alisado de bordes y compatibilidad con un mayor número de formatos de archivo de imagen.
Datos
Visual Basic 6.0 ofrece varios tipos de acceso a datos:
Objetos de datos ActiveX (ADO)
Objetos de datos remotos (RDO)
Objetos de acceso a datos (DAO)
Visual Basic.NET introduce una versión mejorada de ADO denominada ADO.NET. Esta versión está destinada a datos desconectados y mejora la eficacia de ADO cuando se utiliza en aplicaciones distribuidas. ADO.NET ofrece enlaces de datos de lectura y escritura a los controles de los formularios de Windows y de sólo lectura a los formularios Web.
DAO, RDO y ADO aún se pueden utilizar en código de Visual Basic.NET, con leves modificaciones (descritas en la sección relativa al lenguaje de este artículo). No obstante, Visual Basic.NET no es compatible con el enlace de datos DAO y RDO a controles, controles de datos o la conexión de usuario RDO. Si las aplicaciones contienen enlace a datos DAO o RDO, es aconsejable dejarlas en Visual Basic 6.0, o bien, actualizar dichos enlaces a ADO antes de actualizar el proyecto a Visual Basic.NET, ya que los formularios de Windows son compatibles con el enlace a datos ADO. En la ayuda de Visual Basic 6.0 se proporciona información adicional sobre el tema.
En resumen, se recomienda utilizar ADO en proyectos de Visual Basic 6.0.
Actualización
Una vez se ha actualizado el código, Visual Basic.NET crea un nuevo proyecto actualizado y realiza automáticamente los cambios necesarios en el lenguaje y en los objetos. En las secciones siguientes se ofrecen varios ejemplos de cómo se actualiza el código.
De Variant a Object
Las versiones anteriores de Visual Basic eran compatibles con el tipo de datos Variant, que se podía asignar a cualquier tipo primitivo (salvo a las cadenas de longitud fija) Empty, Error, Nothing o Null. En Visual Basic.NET, la funcionalidad de los tipos de datos Variant y Object se combina en un nuevo tipo de datos: Object. El tipo de datos Object se puede asignar a los tipos de datos primitivos Empty, Nothing, Null y, como un puntero, a un objeto.
Una vez se ha actualizado el proyecto a Visual Basic.NET, todas las variables declaradas como Variant se convierten en Object. Asimismo, al insertar el código en el editor, la palabra clave Variant se sustituye por Object.
De Integer a Short
En Visual Basic 6.0, el tipo de datos de los enteros de 16 bits es ahora Short y el de los enteros de 32 bits, Integer (y Long el de los enteros de 64 bits). Una vez se ha actualizado el proyecto, los tipos de variables cambian:Dim x As Integer
dim y as Long
se actualiza a:Dim x As Short
dim y as Integer
Sintaxis de las propiedades
Visual Basic.NET introduce una sintaxis de propiedades más intuitiva, que agrupa Get y Set. En el siguiente ejemplo se muestra la actualización de las instrucciones de propiedades:Property Get MyProperty() As Integer
m_MyProperty = MyProperty
End Property
Property Let MyProperty(NewValue As Integer)
m_MyProperty = NewValue
End Property
se actualiza a:Property MyProperty() As Short
Get
m_MyProperty = MyProperty
End Get
Set
m_MyProperty = Value
End Set
End Property
De los formularios de Visual Basic a los formularios de Windows
Visual Basic.NET cuenta con un nuevo paquete de formularios, los formularios de Windows, que disponen de compatibilidad nativa para la accesibilidad y cuentan con un editor de menús en contexto. Los formularios de Visual Basic existentes se actualizan a formularios de Windows.
Figura 2. Editor de menús en contexto de los formularios de Windows. (Haga clic en la figura para ampliar la imagen.)
Interfaces
En versiones anteriores de Visual Basic, las interfaces para las clases públicas siempre permanecían ocultas para el usuario. En Visual Basic.NET, las interfaces se pueden visualizar y editar en el editor de código. Una vez se ha actualizado el proyecto, se deberá determinar si se desea que se creen automáticamente las declaraciones de interfaz para las clases públicas.
Informe de actualización y comentarios
Una vez se ha actualizado el proyecto, se le agrega un informe de actualización en el que se indican los cambios que se deben implementar en el código actualizado. Además, se agregan una serie de comentarios al código para alertar al usuario de posibles problemas. Estos comentarios aparecen automáticamente en la lista de tareas de Visual Studio.NET.
Figura 3. Los comentarios de actualización se agregan tanto al código de Visual Basic como a la lista de tareas. (Haga clic en la figura para ampliar la imagen.)
Recomendaciones relativas a la programación
En esta sección se ofrecen una serie de recomendaciones sobre cómo escribir el código para minimizar el número de cambios que es preciso introducir tras actualizar el proyecto a Visual Basic.NET.
Uso de enlaces en tiempo de compilación
Tanto Visual Basic 6.0 como Visual Basic.NET son compatibles con objetos enlazados en tiempo de ejecución, operación que consiste en declarar una variable como el tipo de datos Object asignada a la instancia de una clase en tiempo de ejecución. No obstante, durante el proceso de actualización, los objetos enlazados en tiempo de ejecución pueden ocasionar problemas al resolver las propiedades predeterminadas o en aquellos casos en los que se modifica el modelo de objetos subyacente y es preciso convertir las propiedades, métodos y eventos. Por ejemplo, si se dispone de un formulario denominado Form1 con una etiqueta denominada Label1, el siguiente código de Visual Basic 6.0 establecería el título de la etiqueta como “SomeText”:Dim o As Object
Set o = Me.Label1
o.Caption = "SomeText"
En los formularios de Windows de Visual Basic.NET, la propiedad Caption de un control de etiqueta se denomina Text. Una vez que se ha actualizado el código, todas las instancias de la propiedad Caption se sustituyen por Text, pero, dado que un objeto enlazado en tiempo de ejecución no dispone de tipo, Visual Basic no puede detectar el tipo de objeto, o si se deberían traducir algunas de las propiedades. En tales casos, el propio usuario deberá cambiar el código tras la actualización.
Si el usuario rescribe el código utilizando objetos enlazados en tiempo de compilación, la actualización se realiza automáticamente:Dim o As Label
Set o = Me.Label1
o.Caption = "SomeText"
Donde sea posible, es necesario declarar las variables como el tipo de objeto adecuado en lugar de hacerlo simplemente como el tipo de datos Object.
Cuando se utilicen las variables Object y Variant en código de Visual Basic 6.0, es aconsejable utilizar conversiones explícitas al asignar las variables, realizar operaciones en las variables o pasarlas a una función. Por ejemplo, la función de la operación ‘+’ no queda clara en el siguiente código:Dim Var1 As Variant
Dim Var2 As Variant
Dim Var3 As Variant
Var1 = "3"
Var2 = 4
Var3 = Var1 + Var2 'INCORRECTO: ¿Cuál es la función?
¿Cómo se deben agregar Var1 y Var2?, ¿como cadenas o como enteros?
El ejemplo anterior probablemente genere un error en tiempo de ejecución en Visual Basic.NET. Si se vuelve a escribir la línea final utilizando conversiones explícitas, el código funcionará:Var3 = CInt(Var1) + CInt(Var2) 'CORRECTO: conversión explícita
Visual Basic.NET es compatible con las funciones de sobrecarga dependiendo del tipo de parámetro. Por ejemplo, la función Environ dispone dos formularios: Environ( Expression As Integer) As String
Environ( Expression As String ) As String
Visual Basic.NET determina qué función se debe llamar dependiendo del tipo de parámetro. Si se pasa un entero a Environ(), se llama a la versión del entero. Si, por el contrario, se pasa una cadena, se llama a la versión de la cadena. El código que pasa un tipo de datos Variant u Object a una función de sobrecarga puede dar lugar a un error de compilación o en tiempo de ejecución. El uso de una conversión explícita, como la del siguiente ejemplo, garantizará el funcionamiento deseado del código tras su actualización a Visual Basic.NET:Dim a As String
Dim v As Variant
v = "Path"
a = Environ(CStr(v)) 'CORRECTO: conversión explícita
El uso de conversiones explícitas de objetos enlazados en tiempo de ejecución es una buena práctica de codificación, ya que facilita la determinación de la función del código y la actualización del proyecto a Visual Basic.NET.
Uso de Date para el almacenamiento de fechas
Las versiones anteriores de Visual Basic utilizaban el tipo de datos Double para almacenar y manipular las fechas. Esto no se debe hacer en Visual Basic.NET, ya que las fechas se almacenan internamente como tipos Double. Así, aunque el siguiente ejemplo puede resultar válido en Visual Basic 6.0, puede producir un error de compilación en Visual Basic.NET:Dim dbl As Double
Dim dat As Date
dat = Now
dbl = dat 'INCORRECTO: Double no se puede asignar a una fecha
dbl = DateAdd("d", 1, dbl) 'INCORRECTO: Double no se puede utilizar en funciones de fecha
dat = CDate(dbl) 'INCORRECTO: CDate no puede convertir un tipo Double en una fecha
.NET framework proporciona las funciones ToOADate y FromOADate para la conversión entre tipos Double y fechas. No obstante, al actualizar un proyecto a Visual Basic.NET, resulta difícil determinar la función del código que utiliza tipos Double para almacenar las fechas. Para evitar modificaciones innecesarias en el código de Visual Basic.NET, es aconsejable utilizar siempre el tipo de datos Date para su almacenamiento.
Resolución de las propiedades predeterminadas sin parámetros
En Visual Basic 6.0, un gran número de objetos disponen de propiedades predeterminadas que se pueden omitir para simplificar el código. Por ejemplo, TextBox dispone de una propiedad Text, por lo que, en lugar de escribir:MsgBox Form1.Text1.Text
se simplifica del modo siguiente:MsgBox Form1.Text1
La propiedad predeterminada se resuelve al compilar el código. Asimismo, se pueden utilizar propiedades predeterminadas con objetos enlazados en tiempo de ejecución, como en el siguiente ejemplo:Dim obj As Object
Set obj = Form1.Text1
MsgBox obj
En el ejemplo anterior, la propiedad predeterminada se resuelve en tiempo de ejecución y MsgBox muestra el valor de la propiedad predeterminada de TextBox como Text1.
Visual Basic.NET no es compatible con las propiedades predeterminadas sin parámetros y, por tanto, no permite simplificar la programación de este modo. Cuando el proyecto se actualiza, Visual Basic.NET resuelve las propiedades predeterminadas sin parámetros, aunque no puede resolver automáticamente los usos enlazados basados en la resolución en tiempo de ejecución. En estos casos, será necesario modificar el código manualmente. Otro problema es que un gran número de las bibliotecas implementan propiedades predeterminadas utilizando la propiedad _Default, que actúa como un proxy, pasando llamadas a la propiedad predeterminada real. Por tanto, al actualizar un proyecto, algunas propiedades predeterminadas se resolverán en _Default. El código funcionará como siempre, aunque resulte menos comprensible que el código explícito escrito utilizando la propiedad real. Por todas estas razones, es aconsejable evitar el uso de propiedades predeterminadas sin parámetros en el código de Visual Basic 6.0. Por ejemplo, en lugar de escribir:Dim obj As Object
Set obj = Me.Text1
MsgBox obj 'INCORRECTO: Basado en la propiedad predeterminada
MsgBox Me.Text1 'INCORRECTO: Basado en la propiedad predeterminada
utilice:Dim obj As Object
Set obj = Me.Text1
MsgBox obj.Text 'CORRECTO: Se ha resuelto la propiedad predeterminada
MsgBox Me.Text1.Text 'CORRECTO: Se ha resuelto la propiedad predeterminada
Mientras que las propiedades predeterminadas sin parámetros no son compatibles con Visual Basic.NET, las propiedades predeterminadas con parámetros sí lo son. Para comprender la diferencia entre estos dos tipos de propiedades, consideremos que las propiedades predeterminadas con parámetros siempre presentan un índice. Un ejemplo es la propiedad predeterminada recordset ADO: la colección Fields. El código:Dim rs As ADODB.Recordset
rs("CompanyName") = "SomeCompany"
rs!CompanyName = "SomeCompany"
es, en realidad, una forma más simple de escribir:Dim rs As ADODB.Recordset
rs.Fields("CompanyName").Value = "SomeCompany"
rs.Fields!CompanyName.Value = "SomeCompany"
En este caso, la propiedad Fields dispone de parámetros, por lo que no se puede utilizar en Visual Basic.NET. No obstate, la propiedad predeterminada de la propiedad Fields, Value, no presenta parámetros. El uso correcto en Visual Basic.NET es, por tanto:Dim rs As ADODB.Recordset
rs("CompanyName").Value = "SomeCompany"
rs!CompanyName.Value = "SomeCompany"
Este ejemplo y la mayor parte de las propiedades predeterminadas se resuelven al actualizar el proyecto, por lo que su resolución en Visual Basic 6.0 es simplemente una buena práctica de programación. No obstante, se debería evitar la utilización de las propiedades predeterminadas con los tipos de datos Object y Variant, ya que éstas no se pueden resolver y haría necesario modificar manualmente el código del proyecto actualizado.
Uso de comparaciones booleanas con AND, OR y NOT
Las palabras clave And y Or actúan de forma diferente en Visual Basic.NET y Visual Basic 6.0. En Visual Basic 6.0, la palabra clave And ejecutaba un AND lógico o un AND a nivel de bit dependiendo del tipo de operando utilizado (dado que True tiene un valor de –1). En Visual Basic.NET, AND sólo ejecuta un AND lógico y se han agregado varios operadores al lenguaje para poder ejecutar operaciones a nivel de bit: BitAnd, BitOr, BitNot y BitXor.
A continuación se muestra el efecto de esta diferencia:Dim a As Integer
Dim b As Integer
Dim c As Boolean
a = 1
b = 2
c = a And b
MsgBox ("La respuesta es " & c)
Cuando este código se ejecuta en Visual Basic 6.0, la respuesta es False (AND a nivel de bit). No obstante, en Visual Basic.NET, la respuesta es True (AND lógico). Para garantizar que el código no se comporta de forma diferente tras la actualización, Visual Basic.NET incluye las funciones de compatibilidad VB6.And, VB6.Or y VB6.Not, que evalúan AND/OR/NOT del mismo modo que Visual Basic 6.0 (seleccionado "lógico" o "a nivel de bit" en función de los operandos). Al actualizar el código anterior, el resultado sería similar a:Dim a As Short
Dim b As Short
Dim c As Boolean
a = 1
b = 2
c = VB6.And(a, b)
MsgBox ("La respuesta es " & c)
El código actualizado dará lugar a la respuesta False, como el original en Visual Basic 6.0.
Para evitar que el código se actualice a las funciones de compatibilidad, es preciso asegurarse de que las instrucciones AND/OR/NOT utilizan comparaciones booleanas. Así, si el ejemplo anterior se modifica a:Dim a As Integer
Dim b As Integer
Dim c As Boolean
a = 1
b = 2
c = a <> 0 And b <> 0
MsgBox ("La respuesta es " & c)
una vez se ha actualizado el proyecto, el código resulta más familiar:Dim a As Short
Dim b As Short
Dim c As Boolean
a = 1
b = 2
c = a <> 0 And b <> 0
MsgBox ("La respuesta es " & c)
La diferencia está en que cada operador comparado es una expresión booleana y, por tanto, utiliza el AND lógico en Visual Basic 6.0. El AND lógico produce el mismo resultado tanto en Visual Basic 6.0 como en Visual Basic.NET, por lo que el código permanece inalterado. De este modo, se puede cortar y pegar código de Visual Basic.NET a Visual Basic 6.0 y viceversa. No obstante, el código se ejecutará con más rapidez en Visual Basic.NET dado que utiliza el operador nativo AND en lugar de una función de compatibilidad.
Visual Basic.NET utiliza las funciones de las operaciones AND/OR/NOT de forma diferente a Visual Basic 6.0. Veamos el siguiente ejemplo:Dim b As Boolean
b = Function1() And Function2()
En Visual Basic 6.0, se evalúan tanto Function1 como Function2, mientras que en Visual Basic.NET, sólo se evalúa Function2, si Function1 devuelve True. Este fenómeno se conoce como cortocircuito de los operadores lógicos. En la mayoría de los casos, la única diferencia relativa al tiempo de ejecución es que la versión cortocircuitada se ejecuta de forma más rápida. No obstante, si Function2 tiene efectos secundarios, como la manipulación de una base de datos o una variable global, la instrucción presentará un comportamiento en tiempo de ejecución diferente en Visual Basic 6.0. Para evitar esta circunstancia, si las instrucciones AND/OR/NOT disponen de funciones, métodos o propiedades, la instrucción se actualiza a una versión de compatibilidad que evalúe las funciones. El ejemplo anterior se actualizaría de la forma siguiente:Dim b As Boolean
b = VB6.AND(Function1(), Function2())
Para evitar que el código se actualice a la versión de compatibilidad, realice las siguientes modificaciones:Dim b As Boolean
Dim c As Boolean
Dim d As Boolean
c = Function1()
d = Function2()
b = c And d
Asimismo, se debe tener en cuenta que en Visual Basic.NET, el valor subyacente de True ha cambiado de –1 a 1 para facilitar la interoperabilidad de las aplicaciones de Visual Basic con otros lenguajes .NET, resolviendo una gran disparidad con Visual C++. Debido a este cambio, en las aplicaciones de Visual Basic 6.0, se recomienda utilizar la constante True en lugar de -1 y los tipos booleanos en lugar de los enteros para mantener los valores booleanos. Para ilustrar la importancia de todo esto, consideremos el siguiente ejemplo, que produce el resultado True en Visual Basic 6.0 y False en Visual Basic.NET:Dim i As Integer
i = True
If i = -1 Then
MsgBox ("True")
Else
MsgBox ("False")
End If
No obstante, el uso de expresiones booleanas generaría el resultado True tanto en Visual Basic 6.0 como en Visual Basic.NET y el código resultante sería más legible:Dim i As Boolean
i = True
If i = True Then
MsgBox ("True")
Else
MsgBox ("False")
End If
Lo más importante que se debe recordar e implementar en este ejemplo es:
Utilizar siempre las constantes True y False en lugar de los valores subyacentes 0 y –1.
Utilizar el tipo de datos booleanos para almacenar valores booleanos.
Si no se tienen en cuenta estas dos cosas, probablemente se deban realizar un gran número de cambios en el proyecto actualizado a Visual Basic.NET.
Cómo evitar la propagación de Null
Las versiones anteriores de Visual Basic eran compatibles con la propagación de Null, según la cual, cuando Null se utiliza en una expresión, el resultado de la expresión será también Null. En cada uno de los casos del ejemplo siguiente, el resultado de V es siempre Null.Dim V
V = 1 + Null
V = Null + Right$("SomeText", 1)
V = Right("SomeText", 0)
Visual Basic.NET no admite la propagación de Null. La instrucción 1+Null hará que no coincidan los tipos en Visual Basic.NET. Asimismo, mientras que Visual Basic 6.0 dispone de dos versiones de la función Left, Left$ devolviendo una cadena y Left devolviendo una variante que podría ser Null, Visual Basic.NET sólo dispone de una versión, Left, que siempre devuelve una cadena.
Para que sea compatible tanto con Visual Basic 6.0 como con Visual Basic.NET, se recomienda escribir siempre el código para probar Null en lugar de basarse en su propagación. Lo que es más, las siguientes funciones ya no devolverán Null en Visual Basic.NET:
Chr
Mid
Command
Oct
CurDir
Right
Date
RTrim
Environ
Space
Error
Str
Hex
Time
LCase
Trim
LTrim
UCase
La propagación de Null se utiliza normalmente en aplicaciones de bases de datos, en las que es necesario comprobar si uno de los campos de la base de datos contiene Null. En estos casos, se deben comprobar los resultados utilizando la función IsNull() y, a continuación, ejecutar la acción adecuada.
Uso de matrices de límite cero
Visual Basic 6.0 permitía definir matrices con límites inferior y superior de cualquier entero. También se podía utilizar ReDim para reasignar una variante como matriz. Para habilitar la interoperabilidad con otros lenguajes, el límite inferior de las matrices de Visual Basic.NET debe ser cero y no se puede utilizar ReDim, a no ser que la variable se hubiera declarado anteriormente con la matriz Dim As. Aunque de este modo se limiten las posibilidades de definición de matrices, se podrán pasar matrices entre Visual Basic.NET y cualquier otro lenguaje .NET. El siguiente ejemplo muestra esta restricción:Dim a(1 To 10) As Integer 'INCORRECTO: LBound debe ser 0
Dim v
ReDim v(10) 'INCORRECTO: No se puede utilizar ReDim sin Dim
Dim b(10) As Integer 'OK: Crea una matriz de 10 enteros
ReDim b(5) As Integer 'OK: Puede utilizar ReDim en una var. previamente Dimed
Asimismo, en Visual Basic 6.0, Dim (0 a 10) As Integer creaba una matriz de 11 enteros, indizadas del 0 al 10. Mientras que la misma instrucción en Visual Basic.NET crea una matriz de 10 enteros, del 0 al 9.
Uno de los efectos secundarios es la eliminación de Option Base 01 del lenguaje.
El código del proyecto actualizado a Visual Basic.NET no dispone de ninguna instrucción de base de opción. Si el límite de la matriz es cero, se deja inalterada. No obstante, si no lo es, se actualizará a una clase contenedora de matrices, como ocurre en el siguiente ejemplo:Dim a(1 To 10) As Integer
cambia a:Dim a As Object = New VB6.Array(GetType(Short), 1,10)
La clase contenedora de matrices es mucho más lenta que la matriz nativa y el uso conjunto de ambos tipos de matrices en la misma aplicación produce ciertas limitaciones. Por ejemplo, no se puede pasar una matriz contenedora a determinadas funciones con parámetros del tipo Array y quizás no se pueda pasar una matriz contenedora a una clase Visual C# o Visual C++.
Por esta razón, se deben utilizar matrices con límite cero en el código de Visual Basic 6.0, evitar el uso de ReDim como una declaración de matriz y la utilización de Option Base 1.
Uso de constantes en lugar de valores subyacentes
Al escribir el código, se debe intentar utilizar constantes en lugar de valores subyacentes. Por ejemplo, si se está maximizando un formulario en tiempo de ejecución, se debe utilizar:Me.WindowState = vbMaximized 'Correcto: Nombre de constante
en lugar de:Me.WindowStyle = 2 'Incorrecto: Valor subyacente
Me.WindowStyle = X 'Incorrecto: Variable
Del mismo modo, se debe utilizar True y False en lugar de -1 y 0.
En Visual Basic.NET, los valores y, en algunos casos, los nombres de ciertas propiedades y constantes se han modificado. Por ejemplo, el valor de True cambia de -1 a 1. En el proyecto actualizado a Visual Basic.NET, se modifican automáticamente la mayor parte de las constantes. No obstante, si se utilizan valores subyacentes o variables en lugar de nombres de constantes, en muchos casos no se podrá actualizar automáticamente. El uso de nombres de constantes minimiza el número de cambios que se deben introducir.
Matrices y cadenas de longitud fija en tipos definidos por el usuario
Dado que los cambios que permiten a las matrices y estructuras de Visual Basic.NET ser completamente compatibles con otros lenguajes de Visual Studio.NET, las cadenas de longitud fija no se admiten en este lenguaje. En la mayoría de los casos, esto no constituye un problema, ya que existe una clase de compatibilidad que proporciona el comportamiento de las cadenas de longitud fija. Por tanto, el código:Dim MyFixedLengthString As String * 100
se actualiza a:Dim MyFixedLengthString As New VB6.FixedLengthString(100)
No obstante, las cadenas de longitud fija no suponen ningún problema cuando se utilizan en estructuras (también denominadas tipos definidos por el usuario). El problema surge porque la clase de cadenas de longitud fija no se crea automáticamente al crear el tipo definido por el usuario. Asimismo, tampoco se crean matrices de tamaño fijo al crear el tipo definido por el usuario.
Al actualizar el código, los tipos definidos por el usuario con cadenas o matrices de longitud fija se marcan con un comentario en el que se solicita que se inicialice la cadena o matriz de longitud fija antes de utilizar el tipo definido por el usuario. No obstante, se puede evitar esta modificación cambiando los tipos definidos por el usuario de Visual Basic 6.0 para utilizar cadenas en lugar de cadenas de longitud fija y cadenas sin inicializar en lugar de cadenas de tamaño fijo. Por ejemplo:Private Type MyType
MyArray(5) As Integer
MyFixedString As String * 100
End Type
Sub Bar()
Dim MyVariable As MyType
End Sub
se puede cambiar a:Private Type MyType
MyArray() As Integer
MyFixedString As String
End Type
Sub Bar()
Dim MyVariable As MyType
ReDim MyVariable.MyArray(5) As Integer
MyVariable.MyFixedString = String$(100, " ")
End Sub
Cómo evitar las características heredadas
Dado que se han eliminado del lenguaje, se debe evitar el uso de las siguientes palabras clave:
Def
Computed GoTo/GoSub
GoSub/Return
Option Base 01
VarPtr, ObjPtr, StrPtr
LSet
A continuación, se describen estas palabras clave.
Def
En las versiones anteriores de Visual Basic, DefBool, DefByte, DefInt, DefLng, DefCur, DefSng, DefDbl, DefDec, DefDate, DefStr, DefObj y DefVar se utilizaban en la sección de declaraciones de un módulo para definir una serie de variables como un tipo determinado. Por ejemplo:DefInt A-C
definía todas las variables que comienzan con la letra A, B o C como un entero. En lugar de utilizar instrucciones Def, las variables se deben declarar explícitamente.
Computed GoTo/GoSub
Las instrucciones Computed GoTo/GoSub toman la siguiente forma:On x GoTo 100, 200, 300
Visual Basic.NET no es compatible con estas instrucciones, sino que utiliza las instrucciones If y las construcciones Select Case.
GoSub/Return
Visual Basic.NET no es compatible con las instrucciones GoSub y Return. En la mayoría de los casos, estas instrucciones se pueden sustituir por funciones y procedimientos.
Option Base 01
Option Base 01 se utilizaba para especificar el límite inferior predeterminado de una matriz. Como se mencionó anteriormente, esta instrucción se ha eliminado del lenguaje, ya que Visual Basic.NET sólo es compatible de forma nativa con matrices de límite inferior cero. Para admitir matrices de límite inferior distinto de cero es necesaria una clase contenedora.
VarPtr, ObjPtr y StrPtr
VarPtr, VarPrtArray, VarPtrStringArray, ObjPtr y StrPtr eran funciones no documentadas que se utilizaban para obtener la dirección de la memoria subyacente de las variables. Estas funciones no se admiten en Visual Basic.NET.
LSet
En Visual Basic 6.0, la instrucción LSet se podía utilizar para asignar una de las variables de un tipo definido por el usuario a otra de las variables de otro tipo definido por el usuario. Visual Basic.NET no es compatible con esta funcionalidad.
API de Windows
Muchas de las API se pueden utilizar exactamente como en Visual Basic 6.0, aunque es necesario ajustar los tipos de datos correspondientes. El tipo de datos Long de Visual Basic 6.0 es ahora el tipo de datos Integer de Visual Basic.NET e Integer en Visual Basic 6.0 es ahora Short en Visual Basic.NET. Durante la actualización, estos cambios se realizan manualmente y las API simples funcionan igual que lo hacían en Visual Basic 6.0. Por ejemplo:Private Declare Function GetVersion Lib "kernel32" () As Long
Function GetVer()
Dim Ver As Long
Ver = GetVersion()
MsgBox ("La versión del sistema es " & Ver)
End Function
cambia a:Private Declare Function GetVersion Lib "kernel32" () As Integer
Function GetVer()
Dim Ver As Integer
Ver = GetVersion()
MsgBox("La versión del sistema es " & Ver)
End Function
Además de las actualizaciones de tipos de datos numéricos, Visual Basic 6.0 dispone de un tipo de datos de cadenas de longitud fija no compatible con Visual Basic.NET y que se actualiza a una clase contenedora de cadenas de longitud fija. En muchos casos, en Visual Basic 6.0 se puede realizar la misma acción utilizando una cadena normal. Por ejemplo:Private Declare Function GetUserName Lib "advapi32.dll" Alias _
"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As Long) As Long
Function GetUser()
Dim Ret As Long
Dim UserName As String
Dim Buffer As String * 25
Ret = GetUserName(Buffer, 25)
UserName = Left$(Buffer, InStr(Buffer, Chr(0)) - 1)
MsgBox (UserName)
End Function
se puede escribir mejor utilizando una cadena normal explícitamente definida de longitud 25 en lugar de una cadena de longitud fija: Dim Buffer As String
Buffer = String$(25, " ")
Se actualiza a Visual Basic.NET de la forma siguiente:Declare Function GetUserName Lib "advapi32.dll" Alias _
"GetUserNameA" (ByVal lpBuffer As String, ByRef nSize As Integer) As Integer
Function GetUser()
Dim Ret As Integer
Dim UserName As String
Dim Buffer As String
Buffer = New String(CChar(" "), 25)
Ret = GetUserName(Buffer, 25)
UserName = Left(Buffer, InStr(Buffer, Chr(0)) - 1)
MsgBox(UserName)
End Function
En determinados casos, Visual Basic.NET funciona mejor pasando las cadenas a las API, ya que se puede declarar opcionalmente cómo se desea pasar las cadenas utilizando las palabras clave ANSI y UNICODE.
Existen tres casos en los que puede que sea necesario realizar ciertas modificaciones. Uno de ellos es el paso de los tipos definidos por el usuario que contiene cadenas de longitud fija o matrices de bytes a las API. En Visual Basic.NET, puede que se deba modificar el código, agregando el atributo MarshallAs (de System.Runtime.InteropServices) a cada una de las cadenas de longitud fija o matriz de bytes del tipo definido por el usuario. El segundo de los casos es el uso del tipo de variable As Any en una instrucción Declare, no compatible con Visual Basic.NET. Las variables del tipo As Any se utilizaban a menudo para pasar una variable que, bien era una cadena, bien era Null. Se puede sustituir este uso de Visual Basic 6.0 declarando dos formularios de la API, uno con los tipos de datos Long y otro con cadenas. Por ejemplo, la API GetPrivateProfileString dispone de un parámetro lpKeyName de tipo As Any:Private Declare Function GetPrivateProfileString Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As Any, ByVal lpDefault As String, ByVal
lpReturnedString As String, ByVal nSize As Long, ByVal
lpFileName As String) As Long
Se puede eliminar “As Any” sustituyendo Declare con dos versiones, una que acepte un tipo de datos Long y otra que acepte una cadena:Private Declare Function GetPrivateProfileStringKey Lib "kernel32" Alias
"GetPrivateProfileStringA" (ByVal lpApplicationName As String, ByVal
lpKeyName As String, ByVal lpDefault As String, ByVal
lpReturnedString As String, ByVal nSize As Long, ByVal
lpFileName As String) As Long
Private Declare Function GetPrivateProfileStringNullKey Lib "kernel32"
Alias "GetPrivateProfileStringA" (ByVal lpApplicationName As String,
ByVal lpKeyName As Long, ByVal lpDefault As String, ByVal
lpReturnedString As String, ByVal nSize As Long, ByVal
lpFileName As String) As Long
Cuando se desea pasar el valor Null a la API, se utiliza la versión GetPrivateProfileStringNullKey. De este modo, la función se actualiza a Visual Basic.NET.
El último de los casos en el que se deberían realizar cambios es cuando se utilizan API que ejecutan la creación de subprocesos, la subclasificación de Windows, enlace de cola de mensajes, etc. Algunas de estas funciones ocasionarán errores en tiempo de ejecución en Visual Basic.NET. Muchas de estas API tienen equivalentes en Visual Basic.NET o .NET Framework, por lo que es aconsejable actualizar independientemente cada caso.
Consideraciones relativas a los formularios y controles
Visual Basic.NET dispone de un nuevo paquete de formularios, los formularios de Windows, que son completamente compatibles con el paquete de formularios de Visual Basic 6. No obstante, existen ciertas diferencias que se describen a continuación:
Los formularios de Windows no son compatibles con el control contenedor OLE. Se debe evitar el uso de este control en las aplicaciones de Visual Basic 6.0.
Los formularios de Windows no disponen de control de tipo forma. Las formas cuadradas y rectangulares se actualizarán a etiquetas, mientras que las ovales y circulares no se actualizarán. Se recomienda evitar el uso de estas formas en las aplicaciones.
Los formularios de Windows no disponen de control de línea. Las líneas horizontales y verticales se actualizan a etiquetas. Las diagonales no se actualizan, por lo que es aconsejable no utilizarlas.
Los formularios de Windows disponen de un nuevo grupo de comandos de gráficos que sustituyen a los métodos de formulario Circle, CLS, PSet, Line y Point. Dado que el nuevo modelo de objetos es bastante diferente al de Visual Basic 6.0, no se pueden actualizar estos métodos.
En lo que respecta al control Timer, aunque se defina la propiedad Interval como 0, no se deshabilita el cronómetro, sino que el intervalo se restablece en 1. En los proyectos de Visual Basic 6.0, se recomienda definir Enabled como False en lugar de definir Interval como 0.
Los formularios de Windows disponen de dos controles de menú, MainMenu y ContextMenu, mientras que Visual Basic 6.0 sólo dispone de uno, Menu, que se puede abrir como MainMenu o ContextMenu. Los controles de Menu se actualizan a controles de MainMenu, aunque no se podrán utilizar como ContextMenus; será necesario volver a crear ContextMenus.
Los formularios de Windows no son compatibles con el intercambio dinámico de datos (DDE).
Los formularios de Windows no son compatibles con el método Form.PrintForm.
Aunque los formularios de Windows son compatibles con la funcionalidad de arrastrar y soltar, su modelo de objetos es bastante diferente al de Visual Basic 6.0. Por tanto, no se pueden actualizar los métodos y las propiedades de arrastrar y soltar de Visual Basic 6.0.
.NET framework dispone de un objeto Clipboard mejorado (System.WinForms.Clipboard) que proporciona mayor funcionalidad y admite un mayor número de formatos de portapapeles que el objeto Clipboard de Visual Basic 6.0. No obstante, dadas las diferencias entre los modelos de objetos, no se pueden actualizar las instrucciones del Portapapeles.
Los formularios de Windows no son compatibles con la propiedad Name para formularios y controles en tiempo de ejecución. Por tanto, no se debe escribir código que repita la colección Controls buscando un control de un nombre determinado (esta funcionalidad se encuentra ahora disponible utilizando las clases System.Reflection de .NET).
Para garantizar que los formularios se actualizan al tamaño adecuado, se recomienda utilizar siempre el ScaleMode predeterminado de twips en las aplicaciones. Durante la actualización, Visual Basic.NET transforma las coordenadas de los formularios de twips a píxeles.
