Este artículo se aplica a:
.NET Framework 2.0
Visual Basic 2005
Visual Basic 6.0
Resumen: Bill Sempf nos muestra las novedades en la comunicación serie y paralelo en Visual Basic 2005 y los pasos necesarios para migrar el código de hardware de Visual Basic 6.0 heredado a Visual Basic 2005. (13 páginas impresas.) (Este artículo contiene vínculos a páginas en inglés.)
Aunque Visual Basic no ha sido nunca un lenguaje para los controladores de hardware, con frecuencia se ha utilizado para controlar los puertos de comunicación. La comunicación serie y paralelo es una característica del sistema operativo, no del lenguaje, por lo que la comunicación normalmente se realiza mediante comunicación directa con kernal32 a través de un control ActiveX como MsComm o un componente de terceros.
La actualización de aplicaciones de este tipo puede ser todo un reto. Aunque la estrategia general para la comunicación de hardware es la misma para Visual Basic 2005 que para Visual Basic 6.0, se han cambiado los nombres «para proteger a los inocentes» y es posible que resulte difícil encontrar las clases necesarias para realizar las funciones necesarias.
En este artículo, indicaré algunas soluciones habituales para la codificación de dispositivos. Veremos varios dispositivos serie como módems, dispositivos paralelo como impresoras, monitores de vídeo y puertos infrarrojos en términos de comunicación con Visual Basic 2005. Verá que la conversión de una plataforma a otra puede ser una experiencia placentera, ya que al final dispondrá de un código mucho más fácil de manejar.
En esta página
Entradas y salidas de codificación para dispositivos
Impresoras y dispositivos paralelo
Comunicación con IrDA y otros dispositivos de red
Entradas y salidas de codificación para dispositivos
Con Visual Basic 6, un programador debía dirigirse directamente al sistema operativo para comunicarse directamente con el equipo. La versión 2.0 de .NET Framework, la que utiliza Visual Basic 2005, tiene gran parte del control de hardware incrustado, lo que significa que puede hacer en código administrado lo mismo para lo que se debía crear llamadas a Win32.
Como Visual Basic no se suele utilizar para el control de hardware, no se encuentra mucha información sobre esto en la documentación o en la biblioteca de MSDN. Sin embargo, debe saber que no es así porque las clases que controlan el hardware no sean eficaces, sino sencillamente porque los artículos de MSDN se escriben para la mayoría de programadores, y la mayoría de los programadores no utilizan Visual Basic para controlar el hardware.
Tampoco pretendemos decir que Visual Basic 2005 disponga de una representación perfecta del lenguaje de hardware. No la tiene. Tiene un modelo considerablemente mejorado, no obstante, y aquí veremos lo que permite hacer y lo que no.
Por ejemplo, la comunicación de puerto serie ahora queda completamente cubierta. Ya no es necesario recurrir a las bibliotecas de Win32 para casi nada al utilizar los puertos serie. La clase SerialPort se encargará de la mayoría de las necesidades. En concreto, las impresoras también pueden controlarse. El sistema de controlador de vídeo también se puede controlar en Visual Basic 2005. Sólo cuando quiera controlar los componentes de hardware más esotéricos deberá recurrir a las clases de interoperabilidad no administradas.
Como simplificación aún mayor, el objeto My contiene un número considerable de clases que se encargan del hardware del equipo. My.Computer realiza una notable labor al exponer la mayoría de las posibilidades del equipo. Teclados, mouse, monitores, módems y otras características de hardware se incluyen en IntelliSense, lo que facilita enormemente su uso.
Módems y dispositivos serie
El conector de puerto serie en Visual Basic 6 es el control MSComm. Puede utilizar el control MSComm en .NET mediante la interoperabilidad, pero deberá tener Visual Basic 6 instalado en el equipo de desarrollo para evitar problemas de licencias. También puede comunicarse directamente con kernel.dll mediante pinvoke, pero es realmente complicado (aunque puede encontrar un ejemplo en alguna parte de MSDN).
Por el contrario, recomiendo utilizar la clase System.IO.Ports.SerialPort de Visual Basic 2005 que es sorprendentemente parecida al objeto MSComm, pero en código administrado, con lo que aporta todas las ventajas que eso implica. La composición de los métodos tiene un aspecto similar al siguiente:
Antiguos miembros de MSComm
Nuevos miembros de la clase SerialPort
[Text]
[Text]
Evento OnComm
Evento DataReceived
Propiedad CommPort
Propiedad PortName
Propiedad Settings
Propiedades BaudRate, Parity, DataBits y StopBits
Propiedad PortOpen
Propiedad IsOpen
Propiedad Input
Método Read
Propiedad Output
Método Write
Ejemplo: Control de un módem
Escribir código de hardware sin el hardware es difícil. Noah Code (un administrador de programas de Microsoft) tuvo una gran idea y utilizó dos convertidores de USB a serie y un módem nulo entre ellos para probar en su propio equipo. Al conectar un convertidor de USB a serie en el equipo se obtiene un número de puerto COM y si se conectan dos se obtienen dos números de puerto. Si se vinculan con un módem nulo resulta perfecto para enviar y recibir mensajes serie.
Para enviar información al puerto serie deseado es necesario abrir un nuevo objeto SerialPort. El constructor de la clase SerialPort, el método New que se ejecuta al crear una instancia de un nuevo objeto, acepta todos los valores necesarios para establecer la conexión. También puede utilizar las propiedades apropiadas para establecer una conexión. Por ejemplo, examinemos un dispositivo de 56.000 bps en el puerto 4 COM. Utilizando el constructor, crearía una instancia del control como la siguiente:
Dim mySerialPort as SerialPort = new SerialPort("COM4", 56000,
Parity.None, 8, StopBits.One)
Debido a la proliferación de propiedades disponibles como parte del nuevo objeto, también tiene la opción de crear el nuevo SerialPort y establecer las propiedades más adelante. No hay ninguna diferencia funcional, pero es conveniente entender el diferente proceso de pensamiento que intervino en la creación de este objeto.
Dim mySerialPort As SerialPort = New SerialPort()
With mySerialPort
.PortName = "COM4"
.BaudRate = 56000
.Parity = Parity.None
.DataBits = 8
.StopBits = StopBits.One
End With
¿Se pregunta qué es lo que hacen los enumeradores Parity y StopBits? Nada especial. Parity.None es sencillamente una constante para 0, existe únicamente para hacer más legible el código y evitar que los números bailen en el código. Es algo agradable, en mi opinión. En ambos casos estos dos segmentos de código son iguales y es mucho menos críptico que las extrañas cadenas de conexión que requieren los objetos MSComm.
Ahora que tenemos un objeto SerialPort, ¿qué hacemos con él? Se puede enviar y recibir, exactamente igual que con los objetos MSComm.
Como verá en este ejemplo, la parte de enviar de este proceso es muy similar a las funciones Send del control MSComm.
Visual Basic 6
'This is assuming you have an MSComm control on your form called myMsComm myMsComm.Settings = "9600,N,8,1" myMsComm.CommPort = 2 myMsComm.PortOpen = True myMsComm.Output = "Hello World!" myMsComm.PortOpen = False
Visual Basic 2005
Dim mySerialPort As SerialPort = New SerialPort
("COM4", 56000, Parity.None, 8, StopBits.One)
With mySerialPort
.Open()
.Write("Hello world!")
.Close()
End With
Casi exactamente lo mismo y no es una coincidencia. El código necesario para utilizar kernel.dll y escribir en los puertos serie en Visual Basic .NET 2003 tenía 80 líneas. Esta novedad era necesaria.
¿Y en lo relativo a la lectura? Esta acción resulta muy sencilla con Visual Basic 2005. En Visual Basic 6 era necesario manejar tamaños de búfer, bucles y esperar, lo que solía ser difícil. Como Visual Basic 6 no pensaba en secuencias, había que ingeniarse una solución. Por dicho motivo, el código de Visual Basic 6 solía tener el siguiente aspecto cuando se pretendía recibir datos de un puerto ya que era muy dependiente del dispositivo.
'Code from MSDN
Dim txtBuff As String
Dim i As Integer
Dim c As Long
Dim BuffLength
MSComm1.InBufferCount = 0 ' clear inBuffer
Do ' wait for incoming bytes
DoEvents
Loop Until MSComm1.InBufferCount > 0
txtBuff = MSComm1.Input
BuffLength = Len(txtBuff) ' number of received bytes
' (<= 4 bytes)
bstem = Asc(Mid(txtBuff, 1, 1)) ' get module number
bbuff(0) = Asc(Mid(txtBuff, 2, 1)) ' get packet size
If BuffLength < 2 + bbuff(0) Then ' if received bytes<packet size
MSComm1.InBufferCount = 0 ' do it again
Do
DoEvents
Loop Until MSComm1.InBufferCount > 0
txtBuff = txtBuff & MSComm1.Input
End If
For i = 3 To Len(txtBuff) ' write received data
c = Asc(Mid(txtBuff, i, 1)) ' to array bbuff()
bbuff(i - 2) = c
Next
Ahora, podemos escribir un nuevo controlador de eventos respecto al evento DataReceived del objeto SerialPort en torno al que estamos trabajando. Este ejemplo sencillamente escribe en la consola, pero se podría escribir en una base de datos, en una matriz de cadenas o en la pantalla en un control Label.
Private Sub mySerialPort_DataReceived(ByVal sender As Object, _
ByVal e As System.IO.Ports.SerialDataReceivedEventArgs) _
Handles mySerialPort.DataReceived
Console.Write(mySerialPort.ReadExisting())
End Sub
No hay mucha duda acerca del bloque de código que resulta más eficiente. Como Visual Basic 2005 maneja los eventos operativos mejor a través de .NET Framework, puede manejar la entrada serie interrumpida con cierta elegancia. Visual Basic 6 no podía.
¿Qué sucede con USB?
Algunos dispositivos USB se manejan de manera independiente como parte de .NET Framework. Las unidades flash, por ejemplo, se manejan mediante System.IO.DriveInfo y son de tipo DriveType Removable.
En algunas ocasiones se encontrará con algún problema conflictivo de los controladores de hardware, pero hay una regla general. Cualquier dispositivo que utilice el controlador Microsoft predeterminado y tenga un puerto COM podrá utilizarse con la clase SerialPort. Si necesita comunicarse con un dispositivo USB que no entiende RS232, por ejemplo, tendrá que utilizar pinvoke con la API Win32, con HID.dll y con kernel.dll. Consulte los métodos OpenConnection(), GetExternalHubName() y GetNameOf(). Puede obtener más información en el sitio Web de Intel acerca de esto.
Trucos de salón
El control SerialPort tiene algunos aspectos que son realmente agradables. Al ser más generalizado que el control MSComm, puede manejar entradas de una amplia variedad de dispositivos con cierta elegancia, lo que queda evidente no sólo en el nombre del control, sino también en algunos de los miembros de la clase.
•
Utilice la propiedad BaseStream para tomar el control del objeto subyacente que tiene la secuencia de información que entra y sale del dispositivo. Puede realizar modificaciones antes de que el código obtenga los datos sin procesar.
•
Junto con estas mismas líneas, dispone de opciones de codificación, para determinar la codificación antes y después de la transmisión de la secuencia.
•
El control MSComm tiene únicamente una propiedad Input. La clase SerialPort ofrece seis métodos de lectura, entre ellos Read, ReadByte, ReadChar, ReadExisting, ReadLine y ReadTo .
•
La clase SerialPort implementa la interfaz IContainer.
•
Tiene acceso a los eventos ErrorReceived y PinChanged, lo que hará que los controladores de hardware sean mucho más estables en su funcionamiento.
Impresoras y dispositivos paralelo
Hay dos opciones a la hora de imprimir en Visual Basic 6: la colección Printers y la llamada a las API de Win32 mediante winspool.drv, que ofrecen un alto nivel de eficacia y flexibilidad, pero a costa de una buena cantidad de código.
Entre los miembros de la API winspool.drv se incluyen OpenPrinter, StartDocPrinter, StartPagePrinter, WritePrinter, EndPagePrinter, EndDocPrinter y ClosePrinter. Tal como ocurre con muchas llamadas a API, ofrecen una gran funcionalidad, pero la configuración resulta problemática. Resulta imposible encontrar la impresora deseada y con frecuencia un componente que utiliza el controlador winspool recurre a la impresora predeterminada, lo que reduce considerablemente la flexibilidad del equipo.
La colección Printers y el objeto Printer son otra historia: un poco menos de eficacia y un poco menos de flexibilidad. Normalmente un programa recorre la colección para encontrar un objeto que cumpla los criterios necesarios, la primera impresora de la colección con papel de 8×14, por ejemplo, lo que presenta evidentemente sus problemas, pero una vez que se tiene una impresora, es posible hacer prácticamente todo lo que necesite con ella.
Visual Basic 2005 no utiliza ninguno de estos métodos. En su lugar, el objetivo es hacer que el usuario elija la impresora, como ocurre en un programa real. Tras eso, se escribe en la secuencia generada, al igual que la mayoría de los demás lenguajes de la plataforma Windows. Este control, que reemplaza a la anterior colección Printers en funcionalidad si no en intención, está disponible en el cuadro de herramientas de Windows Forms con el nombre de control PrintDialog.
Una de las funciones más habituales para un programa normal de Visual Basic consiste en escribir informes de ancho fijo en una impresora de línea, replicando la funcionalidad del programa COBOL. Cuando estaba vigente Visual Basic 6, la impresora normalmente se encontraba en un puerto de la impresora del equipo. En estos días, la impresora puede estar perfectamente en el otro extremo del mundo. Por este motivo resulta tan útil PrintDialog.
Una vez que tenga la impresora, el diseño del objeto PrintDocument es similar al objeto Printer de Visual Basic 6, con el habitual toque .NET. El objeto PrintDocument permite escribir objetos Graphics o una secuencia Text directamente en la impresora. Para enviar texto a la impresora solía ser necesario código para dividirlo en líneas y utilizar una llamada a Win32. Ahora el objeto Stream y .NET Framework ofrecen una solución mejor.
Visual Basic 6
'This is assuming there is a Printer object set up in the Form designer. Private Declare Function WritePrinter Lib "winspool.drv" _ (ByVal hPrn As Long, pBuf As Any, ByVal cdBuf As Long, pcWritten As Long) As Long Private Declare Function OpenPrinter Lib "winspool.drv" Alias "OpenPrinterA" _ (ByVal pPrinterName As String, phPrn As Long, pDefault As Any) As Long Private Declare Function StartPagePrinter Lib "winspool.drv"
(ByVal hPrn As Long) As Long
'Remember, textToWrite is only one line of text
Public Function WriteTextToPrinter(ByVal textToWrite as String)aslong
Call OpenPrinter(Printer.DeviceName, printerNumber, ByVal 0&)
Printer.FontName = "courier"
Printer.FontSize = 12
lTemp = printerNumber
If lTemp = 0 Then
error = GetLastError
GoTo Exit_Err_Routine
End If
Call StartPagePrinter(printerNumber)
Call WritePrinter(printerNumber, textToWrite,Len(textToWrite),Written)
WriteTextToPrinter = Written
End Function
Visual Basic 2005
Private Sub PrintDocument1_PrintPage(ByVal sender As System.Object,_ ByVal e As System.Drawing.Printing.PrintPageEventArgs)
Handles PrintDocument1.PrintPage
Dim lineCounter As Integer = 0
Dim linesPerPage As Single = 0
Dim line As String = String.Empty
Dim myFont As Font = New Font("Times New Roman", 12)
Dim printStream As StreamReader = New StreamReader("c:\text.txt")
Dim topOfPage As Single = 0
' Calculate the number of lines per page.
linesPerPage = e.MarginBounds.Height / myFont.GetHeight(e.Graphics)
' Iterate over the file, printing each line.
While lineCounter < linesPerPage
line = printStream.ReadLine()
If line Is Nothing Then
Exit While
End If
topOfPage = 100 + lineCounter * myFont.GetHeight(e.Graphics)
e.Graphics.DrawString(line, myFont, Brushes.Black, 100, _
topOfPage, New StringFormat())
lineCounter += 1
End While
End Sub
Aunque el anterior método PrintForm ya no está disponible, hay otras formas mejores de enviar las imágenes a la impresora. Ahora, gracias al resto del espacio de nombres System.Drawing, es posible enviar una imagen directamente a la impresora, incluso una hecha sobre la marcha.
Private Sub document_PrintPage(ByVal sender As Object, _
ByVal e As System.Drawing.Printing.PrintPageEventArgs) _
Handles PrintDocument1.PrintPage
Dim printFont As New System.Drawing.Font _
("Arial", 35, System.Drawing.FontStyle.Regular)
e.Graphics.DrawString("This text is being written to the printer.", _
printFont, Brushes.Black, 10, 10)
'Underline it for fun!
e.Graphics.DrawLine(Pens.DarkCyan, 10, 40, 200, 40)
End Sub
El truco para esto es que PrintPageEventArgs devuelve un objeto Graphics al que se puede hacer referencia y que admite el conjunto completo de métodos Draw… que suele incluir la clase Graphics.
Desgraciadamente, para otros dispositivos de puerto paralelo seguirá siendo necesario buscar el controlador local y llamar a la API Win32. Si hace referencia a la biblioteca IO.DLL en su aplicación (se trata de una biblioteca COM, por lo que generará un componente de interoperabilidad), podrá leer y escribir en dispositivos que no sean impresoras conectadas al puerto paralelo.
Private Declare Sub PortWordOut Lib "IO.DLL"(ByVal Port As Integer, _ ByVal Data As Integer) PortWordOut(23, TextBox1.Text)
Tal como habrá adivinado, es bastante parecido al código de Visual Basic del mismo tipo.
Control de monitor de vídeo
A diferencia de los módems y las impresoras, no se puede hacer mucho en un lenguaje que no sea C++ para interactuar directamente con un monitor o una tarjeta de vídeo. En buena parte, Visual Basic 6 y Visual Basic 2005 limitan la interacción directa con el monitor a la comprobación del tamaño de la resolución.
En Visual Basic 6, un objeto, Screen, se encarga de la mayor parte de esta funcionalidad. Aún más, lo hace en la medida imaginaria llamada Twips, que afortunadamente ha sido reemplazada en Visual Basic 2005 por los más universales píxeles.
Aunque en ciertos aspectos esto es cómodo, oculta cierta funcionalidad que puede ser necesaria en un lugar poco evidente. Para la mayor parte de la funcionalidad de control del monitor, no obstante, funcionaba bastante bien. Una de las funciones más habituales consiste en situar algo en pantalla en una posición concreta. Ahora puede hacerlo en Visual Basic 2005.
Visual Basic 6
Dim xCenter, yCenter As Single xCenter = ((Screen.Width / 2) - (Form1.Width / 2)) yCenter = ((Screen.Height / 2) - (Form1.Height / 2)) Form1.Move xCenter, yCenter
Visual Basic 2005
Dim xCenter, yCenter As Single xCenter = ((My.Computer.Screen.Bounds.Width / 2)-(Me.Bounds.Width/2)) yCenter = ((My.Computer.Screen.Bounds.Height / 2)-(Me.Bounds.Height/2)) Me.Location = New Point(xCenter, yCenter)
Rara vez alguien hace una cosa distinta, pero incluso replicar esto puede ser un problema para muchos programadores, porque todo lo relativo a la pantalla parece encontrarse en un lugar diferente en Visual Basic 2005.
En general, las propiedades del objeto Screen de Visual Basic 6 se corresponden con determinadas partes de Framework. Si desea ver exactamente a qué corresponde cada cosa, puede seguir esta guía:
Visual Basic 6.0
Visual Basic 2005
ActiveControl
System.Windows.Forms.Application.ActiveForm.ActiveControl
System.Windows.Forms.Application.ActiveForm
FontCount
Fonts
System.Drawing.FontFamilies
Nota La manera de enumerar fuentes es diferente. Para obtener más información, consulte Font Changes in Visual Basic .NET.
Height
System.Windows.Forms.Screen.PrimaryScreen.Bounds.Height
MouseIcon
Sin equivalente. Para obtener más información, consulte Cannot set a custom MousePointer.
MousePointer
System.Windows.Forms.Cursor
Nota En Visual Basic 6.0, al modificar Screen.MousePointer cambiaba el aspecto del cursor hasta que se volviese a modificar Screen.MousePointer. En Visual Basic .NET, el cambio permanecerá sólo hasta que se vuelvan a procesar los mensajes de Windows (hasta la siguiente llamada a DoEvents o hasta que termine el procesamiento del programa).
TwipsPerPixelX
Sin equivalente. En Visual Basic .NET, las coordenadas se especifican en píxeles y los twips no se utilizan como unidad de medida.
TwipsPerPixelY
Sin equivalente. En Visual Basic .NET, las coordenadas se especifican en píxeles y los twips no se utilizan como unidad de medida.
Width
System.Windows.Forms.Screen.PrimaryScreen.Bounds.Width
A primera vista, parece realmente confuso. No obstante, pensando con calma, resulta bastante sensato. La clase Screen es una propiedad del formulario. ¿Por qué? Por si hay varios monitores. Estoy sentado en un equipo con varios monitores ahora y acabo de terminar mi aplicación de ejemplo de Visual Basic 6 intentando centrar un formulario. Las fuentes también deben formar parte de una entidad superior. Después de todo, tiene mucho sentido.
Comunicación con IrDA y otros dispositivos de red
Una nota rápida acerca de IrDA. En Visual Basic 6, MScomm controla IrDA, igual que un módem, y debe tener un puerto COM que se pueda leer. Leer y escribir en un dispositivo IrDA se parece a lo explicado en la sección anterior, Ejemplo: Control de un módem. El protocolo es un poco brusco, no obstante, por lo que muchos han recurrido a controles de dispositivos infrarrojos de terceros, como ActiveSMS.
En .NET Framework, el IrDA es un dispositivo de red que se puede controlar mediante System.Net.Sockets, que es un espacio de nombres extremadamente útil y resuelve todos los problemas de dispositivos de red en un útil paquete. Según la documentación de MSDN acerca del espacio de nombres Sockets, los protocolos de red admitidos son los siguientes:
-
Protocolo AppleTalk
-
Protocolo nativo de servicios ATM
-
Protocolo Banyan
-
Protocolo CCITT, como X.25
-
Protocolo MIT CHAOS
-
Protocolo de productos de clúster de Microsoft
-
Protocolo DataKit
-
Protocolo de vinculación de datos directa
-
Protocolo DECNet
-
Protocolo de European Computer Manufacturers Association (ECMA)
-
Protocolo FireFox
-
Protocolo NSC HyperChannel
-
Protocolo de grupo de trabajo IEEE 1284.4
-
Protocolo ARPANET IMP
-
Protocolo de versión 4 de IP
-
Protocolo de versión 6 de IP
-
Protocolo IPX o SPX
-
Protocolo IrDA
-
Protocolo ISO
-
Protocolo LAT
-
Protocolo MAX
-
Protocolo NetBIOS
-
Protocolo activado de puerta de enlace OSI de diseñadores de redes
-
Protocolo Xerox NS
-
Protocolo OSI
-
Protocolo PUP
-
Protocolo IBM SNA
-
Protocolo local a host de Unix
-
Protocolo VoiceView
Ni siquiera yo sé para qué sirven algunos de los protocolos de esta lista y ya llevo mucho tiempo trabajando en esto.
En cualquier caso, la clase que lo hace todo posible se encuentra en el espacio de nombres System.Net.Irda, que sólo es compatible con PocketPC y Windows XP Media Edition. Sin embargo, ofrece bastante eficacia
Dim myIrdaEndpoint As IrDAEndPoint = New
IrDAEndPoint(irDevices(0).DeviceID, "IrDA Test")
Dim myIrdaListener As IrDAListener = New IrDAListener(myIrdaEndpoint)
myIrdaListener.Start()
Dim myIrdaClient As IrDAClient = myIrdaListener.AcceptIrDAClient()
MessageBox.Show(String.Format("Connected to {0}",
myIrdaClient.RemoteMachineName))
myIrdaListener.Stop()
Sigue estando por descubrir si las clases de IrDA se podrán migrar a un portátil que ejecute Vista, pero lo dejaré como ejercicio para el lector.
Conclusión
En vez de una conclusión normal, terminaré comentando el espacio de nombres My.Computer. Aquí se controlan los dispositivos de comunicación, pero hay más componentes de equipos que estos, como todos sabemos.
El objeto My se incorporó como un «selector rápido» en .NET Framework para aumentar la productividad de los desarrolladores. La mayoría de los dispositivos más sencillos que se conectan a un equipo se pueden mantener mediante la clase My.Computer.
My.Computer.Audio: multimedia y altavoces
My.Computer.Info: memoria y procesador
My.Computer.Keyboard: configuración del teclado
My.Computer.Mouse: posición del puntero y más
My.Computer.Network: acceso a las clases del espacio de nombres System.Net
My.Computer.Ports: acceso a los puertos serie comentados al comienzo del artículo
My.Computer.Screen: similar al objeto Screen de Visual Basic 6, del que tanto se ha hablado, y que ya hemos tratado
En algunas maneras, el objeto My.Computer ofrece el fácil acceso al hardware que Visual Basic 6 proporcionaba, mientras que .NET Framework ofrece las posibilidades de una plataforma integrada. Jay Roxe mencionaba que Visual Basic 2005 aporta el «corazón y alma de Visual Basic 6 a .NET» y, de esta manera, al menos, tiene razón.
Nelsongomez's Weblog 