Habrás leído mil veces en otras tantas páginas web que a la hora de diseñar tu aplicación en Visual Basic .NET, lo ideal es olvidarse del antiguo Visual y aprender a generar código puro para el Framework .NET. El problema es que si estás en proceso de adaptación a la nueva plataforma, es más que probable que no sepas cuando estás utilizando una instrucción que viene de antiguo y cuando no.

El quid de la cuestión está en el espacio de nombres Microsoft.VisualBasic, que Visual Studio importa por defecto a tus nuevos proyectos debido a esa sempiterna manía de Microsoft de lo que denominan "compatibilidad hacia atrás", y que a veces es tan bueno y otras veces no tanto. Al principio esto puede parecer útil en un proceso de migración, pero en última instancia te va a resultar contraproducente en tu nuevo proceso de adaptación y aprendizaje.

Vale, y entonces ¿cómo lo hago? Muy fácil, chaval. Te voy a contar un truco de cosecha propia que reducirá tu curva de aprendizaje sustancialmente.

¡Venga, venga, dime! Ya voy, no te aceleres.

Cuando escribas código procura utilizar siempre clases nativas de .NET. Yo no te voy a contar qué se puede y qué no se puede usar, lo puedes encontrar en multitud de sitios web y en la propia documentación de migración de Microsoft. Al terminar el proceso de desarrollo, vete a las propiedades de la aplicación, a la pestaña Referencias, y desactiva la casilla de verificación del espacio de nombres Microsoft.VisualBasic. En este momento, todo tu código se llenará de preciosos errores allí donde haya un pedazo antiguo y no soportado en .NET de forma nativa.

Ahora ya puedes ir depurando cada error hasta que Visual Studio te vuelva a dejar compilar tu bonito assembly libre de código obsoleto.

¡Chupao!

El colmo del frikismo es buscar asociaciones geek en cualquier parte. En este caso me encontré con estas dos matrículas por la calle. ¡Es increíble lo geeks que pueden llegar a ser muchas matrículas!

Una matrícula con mucho "estilo" :)

Qué tiempos aquellos...

Si en el anterior post ensalzaba yo las grandezas de la plataforma .NET, ahora le toca el turno a una ración de fusta contra esta misma tecnología. Y es que así como se me llenaba la boca, embobado, parloteando del ASP.NET 2.0, hoy se me encharca de improperios contra el último ADO.NET.

Y digo yo, ¿por qué le han llamado ADO.NET y no AARGGGH.NET? Esto es tan parecido al ADO de toda la vida como Windows Vista a Windows 3.11 (para trabajo en grupo, rezaba debajo, ¿no?).

Vamos que la intención es similar pero el manejo no se parece en nada de nada. Y no es que las formas hayan cambiado mucho, y uno ya, a su edad, no esté como para andar renovando neuronas cada año y medio, es que el ADO.NET no hay por donde cogerlo. Es muy potente, y muy bonito, y de currelo desconectado y todo lo que quieran, pero no hay Santo Padre que le meta mano.

Lo que antes era Conectar-Abrir-Leer-Cerrar-Desconectar, hoy se ha convertido en Crear el DataAdapter-Generar los comandos-Asignar los comandos al DataAdapter-Configurar-Crear el DataSet-Llenar el DataSet-Cerrar-Leer-Desconectar. Esto, claro está, para extraer un dato y en formato simplificado, que no se le vaya a pasar a usted por la cabeza querer añadir datos a la tabla, que deberá realizar alguna operación que otra más. Un dolor, digo.

Me agrada que los hombres de Redmon renueven tecnologías y amplíen miras, pero, por Dios (y la Virgen, que son dos), no nos hagan la vida más complicada de lo que ya es.

Gracias a la providencia divina, y a la desinteresada aportación de un desarrollador de los de pro, encontré (hace ya) en Planet Source Code una clase para manejar ADO.NET a golpe de comandos al estilo DAO/ADO... <suspiro>qué tiempos aquellos</suspiro>. Para el que le interese, se puede descargar haciendo clic aquí (¡toma normas de utilización de hipervínculos!).

... más me pone. Y es que hay que reconocer que los chicos del tío Bill se salieron desarrollando esta tecnología.

Imaginen el entorno de desarrollo perfecto, un espacio que sea independiente del lenguaje utilizado, que sea multiplataforma y que permita desarrollar aplicaciones de escritorio, aplicaciones web, para dispositivos móviles o servicios basándose en las mismas técnicas de trabajo y en la misma actitud. Eso es .NET.

Imaginen una biblioteca de clases compartida por todos los lenguajes de programación, un entorno de ejecución común, una infraestructura común, un lenguaje intermedio de compilación común y unas especificaciones reguladoras comunes. Imaginen un conjunto de tipos de datos comunes y una arquitectura de acceso a datos común. Imaginen un espacio de trabajo común. ¿Puede haber algo más común que lo común?

Los programadores de Visual Basic ya no podrán ser denostados por los gurús súpermegageeks de ce masmás, porque ahora comparten las mismas características, incluidas las archimanidas herencia, encapsulación y polimorfismo, que son tres cosas raras de los lenguajes orientados a objeto de las que todo hijo de vecino farfulla y luego ni Dios entiende correctamente.

Amén de ello, es importante dedicar un renglón o dos a ensalzar ASP.NET 2.0, que permite desarrollar un sitio web como si de un programilla casero de facturación se tratrase. Ya podemos separar la lógica del diseño, utilizar propiedades y eventos o interacturar con el estado del cliente sin hacer perder tiempo al usuario con eternas recargas de elementos repetidos.

Si a esto le agregamos un poco de SOAP, algo de AJAX (o AVBAX :P), una pizquilla de Silverlight y un chorrito de CSS, obtendremos el batuburrillo perfecto para volvernos locos entre tanta tecnología que, aunque resulte un lío de acrónimos, merece la pena un rato.

NB: Si "SOAP" es jabón en inglés y "AJAX" (pino) es una marca de jabón, progongo denominar FAIRY a la siguiente versión del .NET, o lo que es lo mismo "Framework of Alternative Intelligence Rather Yobbo". No sé, así a bote pronto.

Los programas peer to peer que tan buenos momentos de ocio (y negocio) nos proporcionan, pueden llegar a convertirse en nuestros peores enemigos, chivatos públicos de nuestros secretos mejor custodiados. Nos centraremos exclusivamente en eMule, aunque lo que contaré a continuación puede extrapolarse a cualquier otro software que permita compartir archivos vía Internet y teniendo como base el intercambio entre pares.

Como bien es conocido, este tipo de aplicaciones relacionan usuarios conectados a través de un servidor común que se encarga de poner en contacto a los clientes en función de sus peticiones. Pa' que me entienda usté, señá María, que si quiere conseguir la discografía completa de la Pantoja en emepetrés, usted se me conecta con la mula, busca y automáticamente se empieza a bajar las canciones de aquellas otras personas que ya las tengan y las quieran compartir con su persona de usted.

A la hora de configurar un software de este tipo, uno de los pasos más importantes es el que se corresponde con definir la carpeta o carpetas que queremos compartir con el resto de usuarios de la red. Esta acción, que puede parecer sencilla y sin aparente peligro anejado, puede convertir nuestro pecé en un jugoso reclamo de espías, cotillas y voyeurs ávidos de información ajena que, en la casi totalidad de los casos, ni les va ni les viene.

La falta de información y, quizás, la poca experiencia de muchos nuevos usuarios de estas tecnologías, hace que la tediosa práctica de compartir carpetas muleras cuando se dispone de varios gigas de música, películas y juegos, se despache de un plumazo compartiendo la carpeta "Mis documentos" completa. Craso error.

Si comparte usted su carpeta "Mis documentos" al completo, además de ofrecer a todo pichichi aquello que quiere realmente ofrecer, está compartiendo todo aquello que, seguramente, no esté tan interesado en compartir, léase las fotografías del viaje a Lanzarote, las cartas a su amante, sus vídeos descargados del teléfono móvil o la contabilidad doméstica en esa hoja de Excel que le quedó tan chula.

¿Usted cree que nadie puede ser tan estúpido como para compartir el directorio "Mis documentos" completo? Efectivamente está en lo cierto. Hay todavía estúpidos de mayor rango que ponen a disposición del espía mulero la totalidad de sus discos duros, los pendrives y los discos externos uesebé. Y Dios me perdone por lo de estúpidos, ya que lo más probable es que sean novatos integrales mal informados y peor informatizados por los "especialistas" de alguna de las grandes superficies del sector.

Hacer la prueba es tan fácil como probar. Teniendo un poco de picardía podemos pensar que la mayoría de las cámaras de fotos guardan las mismas en una carpeta llamada DCIM y que, muchas veces, los usuarios copian la carpeta entera al ordenador para pasar las fotografías. También se nos puede venir a la mente que los nombres con los que etiquetan las máquinas digitales las fotografías suelen comenzar por DSC, o por IMG, o por PANA (las Panasonic), o algo similar seguido de un número de orden. Hagan el favor de buscar con su mula imágenes con el texto DSC; o busquen IMG_; o busquen DCIM. Se sorprenderán. Eso sí, si descargan la foto de su vecina en paños menores y dan con sus huesos en la cárcel, no le echen la culpa a este humilde post que sólo quiere ayudar.

También pueden intentar buscar documentos con el nombre currículum o currículum de y se asombrarán de la gente que comparte sus documentos sin saberlo. O prueben lo que se les ocurra que alguien puede guardar en sus "Mis documentos": vacaciones, fiesta, contabilidad, facturas, secreto...

No me sean gañanes y pagafantas y acoten el terreno de caza contra furtivos sin escrúpulos que sólo desean ver sus datos por pura cotillería (o no). Cualquiera puede aparecer pasado mañana en el tubo en aquel vídeo privado que grabó con la parienta aquella noche de juerga.

Aunque parezca mentira (me pongo colorada...) algunos somos adictos a la informática, el intenné y las nuevas tecnologías en general y, al mismo tiempo, aborrecemos con odio patrio todo aquello que huela lo más mínimo a matemático. Sí, sí, mirusté, que algunos fuimos incapaces de aprobar un puñetero examen de matemáticas sin copiar y se nos han dado mal, pero mal, desde pequeñitos. Qué cosa.

Suena a chiste, pero es que yo soy de letras. Estudié latín, historia, literatura y otras cosas de esas que no sirven para nada, sino para llenarte la cabeza de cultura y el pecho de sensibilidad, o sea para mariconadas sin fundamento alguno. Y es que a quién se le ocurre perder el tiempo en aprender, por ejemplo, a escribir bien cuando hoy día se dirime todo a golpe se esemese, y las faltas de ortografía a lo hoygan están de moda no perentoria en la Red de redes.

A algunos, digo, no nos gustan los posts de Microsiervos en los que nos intentan convencer de que es falsa la deducción matemática que demuestra que dos es igual a uno. Seguir esos procesos línea por línea se me hace eterno y aburrido, porque uno no pasó de la suma, la resta y la multiplicación (la división con calculadora), y en cuanto le sacan a algo el factor común por algún lado se pierde irremisiblemente. Además, lo poco que estudié sobre el tema me llega para saber que dos no es igual a uno, con preterición de demostraciones necias.

¿Y no te da vergüenza hablar así de las matemáticas siendo desarrollador informático? Pues no, oiga. Ni pizca. En mi trabajo he tenido nimios problemas para codificar algunos algoritmos que requerían de conocimientos matemáticos, pero con preguntar o buscar la respuesta por ahí he ido saliendo del paso. Afortunadamente estoy rodeado de cerebritos matemáticos que en un pispás te sacan el dichoso factor común a todo lo que se menea y te parametrizan una duda para x igual a lo que te haga falta. Traducirlo a un lenguaje de programación es pan comido. Trabajo en equipo; tú piensas, yo escribo.

En fin, que odio las matemáticas desde los cuadernillos de Rubio y seguirá siendo así por los siglos de los siglos. Supongo que es algún problema cerebral, ya que mi animadversión viene claramente dada por la total incomprensión de la materia. Soy incapaz de entenderlas y ellas no me entienden a mí. Y no me vengan con que no me las han explicado bien nunca, porque por profesores y enseñantes no habrá sido. Sigo diciendo que el problema está en mi masa encefálica y en la falta de las conexiones neuronales requeridas para comprender algo tan, para mí, etéreo.

Quizás algún día, cuando aprenda a despejar x (porque no descarto intentarlo de nuevo), tengo que borrar este post o tacharlo y corregirlo al pie. Ese día seré un hombre nuevo y un hombre renovado. Eso sí, sacando factor común hombre.

Bueno. Por fin vamos a terminar esta serie explicando la mejor utilidad que se le puede dar al AVBAX, esto es, el acceso asíncrono a un archivo XML, que para eso se inventó todo este tinglado; vamos, digo yo...

Supongamos un archivo XML (al que llamaremos archivoxml.xml para seguir con la originalidad) que guarda grupos de música y álbumes publicados y que contenga las siguientes líneas

[código]

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<xml>
  <Album ref="CD142" categoria="Pop">
    <titulo>Guapa</titulo>
    <artista>La oreja de Van Gogh</artista>
  </Album>
  <Album ref="CD720" categoria="Rock">
    <titulo>Zapatillas</titulo>
    <artista>El canto del loco</artista>
  </Album>
  <Album ref="CD024" categoria="Rap">
    <titulo>Vivir para contarlo</titulo>
    <artista>Violadores del verso</artista>
  </Album>
</xml>

[/código]

Veamos primero el procedimiento Sub:

[código]

Sub ObtenerDatos()
  AVBAX.Open "GET", "archivoxml.xml"
  AVBAX.onreadystatechange = Getref("ComprobarEstadoYLeer")
  AVBAX.Send()
End Sub

[/código]

Y ahora la función que recoge los datos (y controla el estado de la transacción):

[código]

Function ComprobarEstadoYLeer()
  If (AVBAX.readyState = 4) Then
    Set XMLDoc = AVBAX.responseXML.documentElement
    Set NodosXML = XMLDoc.ChildNodes
    For Each Elemento In NodosXML
      miCapaContenido.innerHtml = miCapaContenido.innerHtml _
      & "<BR>" & Elemento.ChildNodes(0).NodeName & ": " _
      & Elemento.ChildNodes(0).Text & " // " & _
      Elemento.ChildNodes(1).NodeName & ": " _
      & Elemento.ChildNodes(1).Text
    Next
    miCapaContenido.innerHtml = miCapaContenido.innerHtml _
    & "<BR><BR>" & "Número de registros: " & NodosXML.Length
    Set AVBAX=Nothing
  End If
End Function

[/código]

En este caso deberemos cambiar la propiedad responseText por responseXML, haciendo así que se interprete el archivo con su formato original, y no como un simple fichero de texto. Nos creamos una variable que guardará el objeto de elemento del documento con la propiedad documentElement de responseXML. Así pues, en XMLDoc se almacena el objeto de documento completo.

Para poder acceder a los distintos elementos internos del XML (o nodos para los puristas) nos servimos de otra variable para almacenarlos; esta variable será NodosXML que hace uso de la colección ChildNodes del objeto XMLDoc previamente declarado. Y ahora recorremos todos los nodos con un bucle For... Next.

Mientras leemos los nodos extraemos el nombre de cada subnodo (o nodo hijo con respecto al anterior) con la propiedad NodeName y su contenido textual con la propiedad Text. Los índices 0 y 1 se refieren a cada uno de los subnodos dependientes del anterior (0 para <titulo> y 1 para <artista>).

Entiéndase bien. Los nodos hijos del documento XML (guardados en NodosXML) son los distintos <Album>. Ahora, los nodos hijos de NodosXML son los distintos artistas y títulos de discos.

Todo el resultado se almacena en el innerHtml de la capa (objeto DIV) llamada miCapaContenido.

Por último escribimos el número de registros con la propiedad Length del objeto guardado en NodosXML.

Disponemos de multitud de propiedades para sacarle jugo a este objeto, entre otras: FirstChild, NodeType, NodeValue, OwnerDocument o ParentNode. También métodos: AppendChild, CloneNode, HasChildNodes o RemoveChild. Pero esto ya corre de vuestra cuenta y de vuestras ganas de investigar. Ajo y agua.

Pos vale. Pos malegro. Y además de poder leer un archivo de texto alojado en el servidor remoto, ¿pa' que más me sirve esto?

No se me alteren, por Dios, no se me alteren. En este segundo post vamos a explicar cómo hacer peticiones GET y POST a una página web con paso de parámetros y todo. ¡Acérquense que estamos que lo regalamos! ¡A regolvé, a regolvé!

Efectivamente, con el objeto XMLHttpRequest también podemos capturar el resultado de la petición parametrizada que escupe un ASP, o un PHP, o cualquier otro, actuando contra una base de datos.

Para peticiones GET deberemos especificar los parámetros en la línea del Open así (por ejemplo):

[código]

VBAX.Open "GET", "index.html?parametro1=Hola&parametro2=" & _
Escape(Cadena2), True

[/código]

Donde Cadena2 es una variable previamente definida y con valor asignado, y Escape es una función VBScript que codifica una cadena transformándola en válida para una transacción HTTP. Esta función debe utilizarse siempre, o casi siempre, para evitarnos problemas a la hora de realizar las peticiones. Ya sabéis, nos convierte los caracteres raros para una URL (como espacios, eñes, tildes y demás) en otros todavía más raros (como +, %F1, etcétera) pero comprensibles para el navegador. ¿Cuando hablarán derecho estos paratos?

Para peticiones POST la cosa cambia un poco. Los parámetros han de pasarse desde el método Send de la siguiente manera:

[código]

AVBAX.Open "POST", "index.html", True
AVBAX.Send("parametro1=Hola&parametro2=" & Escape(Cadena2))

[/código] 

Como se comentó en el anterior post, entre ambas líneas de código irá la que indica la función que recogerá los resultados (la del onreadystatechange).

Uno que viene mamado del BASIC del Spectrum y aborrece todo lo que suene a Java y JavaScript, tuvo que aguzar el ingenio para no perder el tren AJAX sin necesidad de utilizar una sola llave de código ni un anodino masmás de esos (que vienen a ser el contador suma de toda la vida, vaya). Por ello, y tras horas de prueba-error, llegó a la conclusión de que había inventado el AVBAX, o lo que es lo mismo, el AJAX vía VBScript. Días más tarde descubrió que ya estaba inventado y que, incluso (¡será posible!), algún avezado programador chino, o japonés, o tailandés, o lo que sea, le había llamado también AVBAX. Snif, snif.

Autorías aparte, el asincronismo con VBScript y XML es AJAX variando el leguaje script, por lo que el objetivo final es el mismo y el resultado igualico igualico. Lo único que, como no tengo la menor intención de aprender más JavaScript del que ya sé, a mí me resulta más sencillo e intuitivo.

Intentemos arrojar un poco de luz sobre el tema de la apotema comenzando, en este primer post, con un ejemplo que accede a un simple archivo de texto plano.

Al igual que con JavaScript, el primer paso consiste en crear el objeto XMLHttpRequest para poder acceder de manera asíncrona a un documento XML. Esto lo hacemos de aquesta forma:

[código]

Dim AVBAX
Set AVBAX = CreateObject ("Msxml2.XMLHttp")

[/código]

Lo siguiente es definir el procedimiento Sub para obtener los datos del archivo de texto al que, haciendo gala de gran originalidad e inventiva, llamaremos archivo.txt.

[código]

Sub ObtenerDatos ()
  Dim URL
  URL = "archivo.txt"
  AVBAX.Open "GET", URL, True
  AVBAX.onreadystatechange = Getref ("ComprobarEstadoYLeer")
  AVBAX.Send ()
End Sub

[/código]

El método Open prepara una conexión HTTP a través del objeto XMLHttpRequest. El primer parámetro es el método de conexión (GET o POST); el segundo parámetro es la URL para la petición HTTP (en este caso un simple fichero textual alojado en el mismo directorio que el HTML); el tercero es un parámetro booleano que toma valor True para utilizar el método asíncrono y False para el método síncrono (valga este último palabro, inexistente para el DRAE).

Por su lado, la propiedad onreadystatechange asigna la función que se ejecutará cuando la propiedad readyState (ver más adelante) cambie de valor. En este caso asignamos una función que se llama ComprobarEstadoYLeer, que definiremos a continuación. Send envía los datos de la petición.

readyState toma los siguientes valores:

0 - Sin inicializar.
1 - Abierto.
2 - Enviado.
3 - Recibiendo.
4 - A punto.

Nosotros sólo podemos acceder a la respuesta cuando readyState sea igual a 3 ó 4, de ahí la condicional.

responseText devuelve el texto del documento descargado en la petición y, con la propiedad innerHtml del objeto miCapaContenido (que es una capa u objeto DIV), escribimos el resultado en pantalla. Al final descargamos el objeto de la memoria.

Por último queda decir que en el evento onClick de un botón de comando, por ejemplo, haríamos la llamada al procedimiento Sub y listo, Calisto. Chupado. No me digan.

Por supuesto, todo el código antes expuesto habría de ir contenido entre las marcas de rigor.

Bienvenidos a todos y a todas a mi nuevo bitacorilla con ínfulas de weblog a lo Microsiervos. Ya sé que, a día de hoy, es imposible penetrar en este mundo de los blogs por la puerta grande, pero uno conoce alguna que otra puerta del foro e intentará, cuando menos, entretener e informar un poco al personal de lo que se cuece por los mundos recónditos de la tesnología.

Si al menos consigo que pases un ratillo agradable leyendo estos posts, pues me doy con un canto en los dientes y me cuelgo la primera medalla.

Lo dicho, eres libre de entrar o no, pero si entras, no vas a poder salir de aquí. Que lo sepas...