En VB clásico había dos funciones muy prácticas para muchos cometidos que permitían obtener el código ASCII de un caracter y viceversa, a partir de un código ASCII sacar el caracter que le correspondía. estas funciones se llamaban Asc y Chr respectivamente.

En C# no existen como tales, pero son muy fáciles de simular igualmente, así:

///Hace falta poner using System.Text al principio para esta
public static int Asc(string s)
  {
   return Encoding.ASCII.GetBytes(s)[0];
  }

  public static char Chr(int c)
  {
   return Convert.ToChar(c);
  }

Es algo muy sencillo pero que puede resultar útil a los programadores principiantes de C# que viene de VB6.

Otro detalle sencillo pero interesante, del estilo del que comentaba ayer, que me ha surgido últimamente.

Si codificas desde ASP una cadena como URL (es decir, sustituyes los caracteres no ASCII por su representación en forma '%CC', siendo CC el código que lo representa) obtienes cadenas que puedes pasar por GET a un navegador sin problemas de mala codificación de caracteres. Esta es la teoría. En la práctica depende.

El otro día estaba llamando desde ASP 3.0 clásico a una página escrita en ASP.NET 1.1 a la que le paaba desde ASP3 un parámetro con un texto mediante GET. Al recoger el valor del parámetro en la página ASPX los caracteres especiales, cómo tildes o 'eñes' desaparecían o estaban cambiados y eso que antes de hacer la llamada a la ASPX codificaba con Server.URLEncode la cadena que estaba pasando. Era raro, porque en ASPX lo único que hacía era leer el valor del primer parámetro del Querystring.

Usando un decompilador vi que lo que ocurría es que ASPX decodifica los parámetros del QueryString partiendo de la base de que están codificados como UTF-8. Sin embargo ASP3 los codifica como UTF-7. Es decir, que al deshacer la codificación con Server.UrlDecode, ASPX estaba haciéndolo mal.

Es un problema tonto pero bastante peliagudo :-(

La solución, extraer "a pelo" la parte de parámetros de la URL actual (muy fácil con una expresión regular o directamente buscando la interrogación de la URL), y decodificar su contenido usando UTF-7 así:

public static string URLDecode(string url)
  {
   return HttpUtility.UrlDecode(url, Encoding.UTF7);
  }

Con esto solucioné el problema y la comunicación entre ambas aplicaciones se realizó perfectamente. Espero que este detalle le pueda servir a alguien más.

Estos días he tenido quye trabajar un poco con cadenas que representaban números hexadecimales y, la verdad, en C# la cosa no es tan intuitiva cómo solía ser con VB y sucedáneos (VBA, VBScript...). De todos modos no es nada complicado tampoco, sólo algo menos intuitivo.

Para facilitar las cosas he escrito un par de funciones sencillitas que permiten transformar una cadena representando un número hexadecimal en número en base decimal (en un entero, claro), y viceversa: cómo expresar un decimal en formato hexadecimal de texto.

  public static long HexToInt(string sHexVal)
  {
        return Int64.Parse(sHexVal, NumberStyles.HexNumber);
  }

  public static string IntToHex(long num)
  {
        return String.Format("{0:x}", num).ToUpper();
  }

Son sencillas pero a más de uno le evitarán romperse el coco unos minutos buscando cómo conseguirlo ;-)

Microsoft ha anunciado que ha bautizado la próxima versión de su sistema operativo, hasta ahora conocida con el nombre de Longhorn, como Windows Vista. ¿¿¿No os parece un nombre horrible????
El lanzamiento de la versión definitiva se producirá en la segunda mitad de 2006, cinco años después del XP, lo que supone el mayor lapso entre lanzamientos del sistema operativo.

Windows Vista (para mi seguirá siendo Longhorn) será la versión doméstica. Existirá una versión para servidores que saldrá al mercado en principio en 2007 y no llevará el nombre de Vista sino que seguirá la convención de Windows Server (o sea que será Windows Server 2007 o así).

¡Estoy espeluznado!. Aparte de por el nombre horrible, porque aún lo acaban de anunciar hace unas horas y en Wikipedia ya tienen un dossier actualizado sobre el sistema. Es increible. De hecho todo ese enorme texto lo han escrito entre ayer y hoy. Deebe de ser peña pagada por Microsoft, digo yo ;-)

En http://www.vistawindows.us/ se puede ver un vídeo (bastante americanada) de la presentación en público del sistema.

Con la plataforma .NET 2.0 es muy fácil obtener una lista con los servidores SQL Server que están disponibles en nuestra red. Antes era muy complicado porque había que recurrir COM Interop y a ODBC para poder hacer uso de las poco conocidas funciones disponibles para ello (vea por ejemplo este artículo en CodeProject).

Ahora es muy fácil, pues basta con usar la nueva clase SqlDataSourceEnumerator. Este enumerador dispone de un método llamado GetDataSources que devuelve una tabla con los datos de las instancias de SQL Server detectadas en la red local. La tabla dispone de cuatro campos (o columnas) que son los siguientes:

• ServerName: el nombre del servidor SQL
• InstanceName: el nombre de la instancia detectada.
• Version: el número de versión de la instancia detectada.
• IsClustered: indica si el servidor detectado forma parte de algún cluster.

Un ejemplo de uso sería el siguiente:

            SqlDataSourceEnumerator Descubridor_de_sql = SqlDataSourceEnumerator.Instance;
            DataTable sqls = Descubridor_de_sql.GetDataSources();
            foreach (DataRow servSQL in sqls.Rows)
            {
                Console.WriteLine("///////////////////////////////////////////////////////////");
                Console.WriteLine("Nombre del servidor:" + servSQL["ServerName"]);
                Console.WriteLine("Nombre de la instancia:" + servSQL["InstanceName"]);
                Console.WriteLine("Versión:" + servSQL["Version"]);
                Console.WriteLine("¿Está en cluster?:" + servSQL["IsClustered"]);
            }

El resultado del código anterior en mi máquina es el siguiente:

///////////////////////////////////////////////////////////
Nombre del servidor:TABLETPC
Nombre de la instancia:
Versión:8.00.194
¿Está en cluster?:No
///////////////////////////////////////////////////////////
Nombre del servidor:TABLETPC
Nombre de la instancia:SQLEXPRESS
Versión:9.00.1116
¿Está en cluster?:No

Para utilizar el enumerador en lugar e crear una nueva instancia de la clase SqlDataSourceEnumerator, se debe usar su propiedad estática Instance que devuelve una instancia del enumerador. Esto es así ya que la clase carece de un constructor (se instancia internamente).

Puede que no descubra todos los servidores cercanos (dependerá de los cortafuegos que haya por el medio. De hecho, en mi equipo con Windows XP Service Pack a menos que desconecte el cortafuegos (o permita el uso del puerto 1443) no es capaz de descubir los dos servidores locales que tengo (un SQL Server 2000 y un 2005), así que ojo porque su utilidad puede ser limitada en ciertos entornos, si bien seguramente servirá bien para aplicaciones empresariales.

Cuando creas un servicio Web con ASP.NET y te conectas a su .ASMX con un navegador te aparece una lista de métodos dentro de una bonita página generada automáticamente al vuelo por ASP.NET para la ocasión.

Si estamos accediendo en local, al pulsar sobre cualquiera de estos métodos si éste tiene parámetros simples (cadenas, números y cosas fáciles de meter en un formulario Web) se nos permite probar directamente el servicio sin necesidad de un programa cliente, lo cual es muy útil para depurarlos y probarlos en una instalación o incluso en medio del desarrollo.

En ASP.NET 1.0 se podía hacer esto tanto en local como en remoto pero en la versión 1.1 cambiaron el comportamiento y por seguridad sólo se puede probar en local, obteniendo un mensaje si lo hacemos en remoto.

Sin embargo puede ser muy útil probarlo en remoto si detectamos problemas desde un cliente. Podemos habilitarlo con tan sólo añadir estas líneas al archivo web.config del servicio Web en el servidor:

<system.web>
  <webServices>
    <protocols>
     <!-- <add name="HttpPost"/> -->
     <add name="HttpGet"/>
    </protocols>
  </webServices>
</system.web>

Fíjate que momentáneamente se desactiva HTTPpost y se deja HTTPGet. Recuerda quitarlo cuando no lo necesites.

Esto lo he sacado de la lista de correo de la Universidad (no voy a decir de cual), y me ha parecido buenísimo (cosa rara viniendo de esa lista, así que doble mérito). No sé de donde ha salido pero lo pongo aquí para referencia y comentarios :-)

En un anterior post, demostré con un sencillo ejemplo el uso del nuevo espacio de nombres de .NET 2.0 llamado NetworkInformation creando un ejemplo de utilidad para hacer Ping síncrono a otras máquinas de manera sencilla.

He seguido jugueteando con él un rato y en esta ocasión voy a mostrar cómo usarlo para verificar si existe o no conectividad en alguna de las tarjetas de red disponibles en el equipo. Se trata de una tarea extremadamente sencilla ya que basta con escribir:

bool disponible = NetworkInterface.GetIsNetworkAvailable();

¡Listo! Con que cualquier adaptador de red disponga de conectividad devolverá true.

Lo interesante sin embargo es poder detectar de inmediato los cambios de conectividad cuando se produzcan, de modo que en una comunicación podamos responder a la caida de la red  así como a su restablecimiento.

Una primera forma de hacerlo "a lo bestia" sería usar un temporizador para que compruebe la información anterior cada segundo o así. Esto, aparte de ser ineficiente, no es necesario.

Existe una nueva clase especializada llamada NetworkChange que se usa para estos menesteres. Dispone de dos eventos llamados NetworkAvailabilityChanged y NetworkAddressChanged que permiten averiguar respectivamente si ha cambiado la conectividad y la dirección IP de alguna tarjeta.

Usarlos es muy fácil, basta con declarar los eventos, asi:

        public static void Main()
        {
            InitializeComponent();

            NetworkChange.NetworkAvailabilityChanged += new NetworkAvailabilityChangedEventHandler(OnConexion_Desconexion);
            NetworkChange.NetworkAddressChanged += new NetworkAddressChangedEventHandler(NetworkChange_NetworkAddressChanged);
           Console.ReadLine();
        }

        private void OnConexion_Desconexion(object sender, NetworkAvailabilityEventArgs disponibilidad)
        {
            MessageBox.Show(String.Format("¿Red disponible?: {0}", disponibilidad.IsAvailable));
        }

        void NetworkChange_NetworkAddressChanged(object sender, EventArgs e)
        {
            MessageBox.Show("Ha cambiado la dirección IP de alguna tarjeta");
        }

Como se puede observar la información ofrecida en los eventos no es mucha, pero al menos nos permite averiguar cuando se da alguno de estos cambios. Es una pena que, por ejemplo, en el objeto sender no obtengamos una referencia a una clase NetworkInterface que nos permitiese saber exactamente en cuál se han producido los cambios. Sólo sabemos que se producen pero no donde o cual es la nueva IP, por ejemplo. Una lástima ya que ello nos obliga a averiguarlo recorriendo la colección de interfaces de red y compararla con una pre-guardada.

La verdad es que no hubiera costado mucho y hubieran cerrado el espacio de nombres mucho más dignamente. De todos modos esto es muy útil.

Leyendo el blog de Curt Monash en ComputerWorld me he encontrado con una curiosidad que, a mi por lo menos, me ha sorprendido mucho... y es que al parecer la primera versión de VB la creó una conocida empresa de servicios profesionales de la India, y no Microsoft.

Puedes leer el texto completo en Microsoft = biggest R&D outsourcer of all..

Cuando definimos un campo (normalmente una clave primaria) de una tabla de base de datos como Autonumérico lo que estamos indicando es que, el propio gestor dedatos, al introducir un nuevo registro en la tabla generará un valor consecutivo para la secuencia, aislándonos del problema que representaría el tener que hacerlo nosotros mismos (transacciones, bloqueos, etc...).

Una vez insertado el registro en la mayor parte de las ocasiones es necesario averiguar qué valor se ha generado. Los SGBD más importantes del mercado ofrecen una forma sencilla de obtener este dato, aislándonos del hecho que desde que lo hayamos generado hasta que lo consultemos (dentro de la misma conexión) éste ya puede haber aumentado (en una inserción paralela de otra conexión).

La forma de obtener esta información es la siguiente:

· SQL Server 2000 o superior:

SELECT SCOPE_IDENTITY()

en SQL 7.0 y anteriores era SELECT IDENTITY() que aún funciona, pero que devuelve el último autonumérico generado en cualquier lugar, no dentro del ámbito actual, por lo que hay que usarlo con más cuidado.

· MySQL:

SELECT LAST_INSERT_ID()

· Oracle:

SELECT Secuencia.CURRVAL FROM DUAL

En Oracle no existen los autonuméricos como tales. Lo que existen son las secuencias que se definen aparte y que, como su propio nombre indica, son secuencias con nombre que se ocupan de generar números consecutivos que luego asignamos a un determinado campo para "simular" un campo autonumérico. En la sentencia anterior hay que especificar, por tanto, el nombre de la secuencia para obtener su último valor.

He de confesarlo, no lo sabía, pero es que aunque uso mucho el teclado miro poco para la pantalla y se me había pasado este detalle.

Sin embargo hoy, leyende un artículo de Coding4fun, lo comentaba el autor y me he fijado.

En los entornos multi-documento co pestañas para pasar de unos a otros se usa CTRL+TAB. Yo lo hago continuamente. En Visual Studio 2005 han ido un paso más allá y si pulsas esa combinación aparece un diálogo como este:

Mantén CTRL pulsado y con TAB puedes ir variando la posición dentro de la lista de archivos en la que estás. Con las teclas del cursor podrás moverte de una lista a otra. Puedes moverte por los archivos o por las herramientas que tengas abiertas, obteniendo información en la parte inferior.

En la versión en castellano de la Beta 2 el texto es demasiado largo y se solapa (míralo en la figura). Ya lo he notificado y supongo que lo solucionarán.

En fin, una chorradilla pero que denota calidad y me ha parecido chulísima.

.NET 2.0 dispone de un nuevo espacio de nombres pensado específicamente para crear aplicaciones de diagnóstico de redes. Se trata de System.Net.NetworkInformation.

En él encontramos clases para obtener información sobre las interfaces de red de un equipo, información trasegada por la red, recibir notificaciones (por ejemplo de que se ha modificado la dirección de una tarjeta), etc... Es muy interesante echarle un vistazo.

A mi me ha gustado, para hacer un primer ejemplo, la clase Ping, que permite (claro está) hacer un "ping" ICMP a cualquier nodo de una red. Permite hacerlo de forma síncrona o asíncrona. En la versión anterior de la plataforma había que hacerlo "a pelo" y era bastante complicado. Ahora es sencillísimo.

Por ejemplo, el siguiente código realiza cuatro pings a Google y devuelve los resultados de cada petición.

using System.Net;
using System.Net.NetworkInformation;

IPAddress ip = IPAddress.Parse("66.249.87.104"); //Google
Ping ping = new Ping();
for (int i = 0; i < 4; i++)
{
    PingReply pr = ping.Send(ip);
    Console.WriteLine("Respuesta desde {0}: bytes:{1} tiempo={2} ({3})", pr.Address, pr.Buffer.Length, pr.RoundtripTime, pr.Status.ToString());
}
Console.ReadLine();

En la consola veremos aparecer algo similar a esto:

Respuesta desde 66.249.87.104: bytes:32 tiempo=102 (Success)
Respuesta desde 66.249.87.104: bytes:32 tiempo=95 (Success)
Respuesta desde 66.249.87.104: bytes:32 tiempo=94 (Success)
Respuesta desde 66.249.87.104: bytes:32 tiempo=97 (Success)

Es muy fácil crear una aplicación clónica del "ping" de la línea de comandos de Windows, o mejor aún, crear una versión con Windows Forms que haga más cosas y sea más fácil de usar. ¡El que se anime que me lo mande!

Esta clase Ping es super-útil para comprobar a intervalos regulares si unservidor está activo o no, o hacer un barrido de una red para descubrir qué nodos están activos.

Igual hago algún ejemplo más chulo con otras clases de este espacio de nombres y lo pongo en un post posterior.

En mi anterior post comentaba que los menús de aplicaciones escritas para Smartphone con la .NET Compact Framework tienen una serie de limitaciones entre las cuales se incluye la de que es "imposible" ocultarlos.

Tal y como mencioné entonces, Microsoft recomienda deshabilitarlos y quitarles el texto. En este post precedente hice un ejemplo con una clase nueva para menús ocultables que seguía la recomendación de Microsoft. El resultado es bastante feo como se veía en las figuras y, la verdad, a mi no me convence en absoluto.

Así, me planteé como tarea de entretenimiento para cuando tuviese un rato libre el crear un nuevo tipo de menú que sea ocultable de verdad.

La primera idea que tuve fue recurrir a la API del sistema con Interop y utilizar algunas funciones nativas de manejo de menús pero se convierte en un lío demasiado gordo porque la clase MenuItem ni siquiera ofrece forma directa de averiguar el manejador del menú que gestiona.

La idea que he seguido al final es mucho más sencilla, aunque como verás en el código también tiene su complicación.
La figura del lateral muestra el aspecto de un menú antes de ocultar uno de sus elementos.
La siguiente figura muestra el resultado obtenido al ocultar el segundo menú, que es el que cabría esperar de una propiedad Visible (que es la que he añadido):

Lo que he hecho es manipular la colección MenuItems del padre del menú a ocultar. Por ejemplo, ocultarlo es muy sencillo ya que lo que hago en realidad es quitarlo directamente:

this.Parent.MenuItems.Remove(this);

La complicación viene a la hora de hacerlo visible ya que hay que volver a colocarlo en el mismo lugar. Para ello almaceno en variables privadas de la clase MenuOcultable una referencia al padre y la antigua posición. Al colocarlo de nuevo hay que ponerlo al final con el método Add, y mover los que le preceden al final también ya que este método sólo permite colocar menús al final (como el Push de una pila). Además hay que tener en cuenta que no se pueden quitar todos los elementos o se gebera un error.

En fin, lo mejor es que descargues el ejemplo y el código y lo veas tú mismo.

La clase funciona con cualquier menú en cualquier posición y con sub-menús o sin ellos. La única limitación que tiene (aparte del hecho de no poder usar el diseñador, que por otra parte es poco útil), es que no se puede ocultar un menú si es el único que queda. En este caso si lo hacemos se genera una excepción del tipo NotSupportedException. Esto es una limitación de la plataforma.

Pienso que es fácil de superar clonando al padre del menú único, y poniendo la copia (que ya no tiene hijos) en lugar del original. Luego habría que restaurar el anterior. De todos modos no lo he implementado porque tampoco me parece tan importante y me ha dado pereza. Si alguien completa mi código con esto, por favor, que me escriba para mandármelo. ;-))