Split, función vs método

En VisualBasic.NET existen dos definiciones para la instrucción Split, una es un método y la otra una función que, si bien pienso que deberian funcionar exactamente igual, tienen sus particularidades.

La función Split está definida en el NameSpace Microsoft.VisualBasic mientras que el método Split se encuentra en el NameSpace System.String. En principio parece ser que el NameSpace Microsoft.VisualBasic se definió como un conjunto de instrucciones para facilitar la migración de aplicaciones hechas en versiones anteriores de VisualBasic a .NET por lo que debemos entender que es el método Split el que Microsoft propone para los nuevos desarrollos en .NET

Para quien no lo sepa Split se utiliza para dividir una cadena en subcadenas utilizando uno o varios caracteres como elemento de corte, es decir, si tenemos el texto "Texto1@Texto2@Texto3" podriamos obtener tres cadenas independientes "Texto1", "Texto2", "Texto3" llamando al método (o a la función) Split con @ como caracter de corte.

Utilizando ambos métodos se obtiene que:

SubCadenas(0) = "Texto1"
SubCadenas(1) = "Texto2"
SubCadenas(2) = "Texto3"

El problema es que, en ocasiones necesitamos especificar varios caracteres de corte, por ejemplo, si en lugar de @ tenemos dos caracteres, por ejemplo @& y la cadena de texto original fuera "Texto1@&Texto2@&Texto3" se supone que deberiamos obtener el mismo resultado llamando al método o a la función utilizando esos caracteres pero realmente obtenemos lo siguiente.

Con el método Cadena.Split("@&") el resultado es:

SubCadenas(0) = "Texto1"
SubCadenas(1) = "&Texto2"
SubCadenas(2) = "&Texto3"

Mientras que utilizando la función Split(Cadena, "@&") si se obtiene:

SubCadenas(0) = "Texto1"
SubCadenas(1) = "Texto2"
SubCadneas(2) = "Texto3"

¿A que se debe esta discrepancia? el problema es que el método Split acepta una variable de tipo caracter como parámetro, es decir, un único caracter por lo que al pasarle "@&" realemnte solo esta teniendo en cuenta el caracter @ mientras que & es despreciado.
La función Split si acepta un String como parámetro por lo que si se estan considerando ambos caracteres y su resultado es el esperado.

Realmente el método Split si tiene una sobrecarga en la que se puede indicar un valor de tipo String (realmente un array de strings) pero dicha sobrecarga, tiene, además, otro parámetro StringSplitOptions que, en este caso no nos interesa pero a no ser que lo especifiquemos no conseguiremos que el método Split funcione como deseamos así que la llamada correcta seria:

De esta forma el valor de SubCadenas si es el mismo que utilizando la función Split, es decir:

SubCadenas(0) = "Texto1"
SubCadenas(1) = "Texto2"
SubCadneas(2) = "Texto3"

Pienso que en la definición del método Split se les pasó por alto hacer una sobrecarga para permitir un parámetro String de forma similar a la función Split, por lo menos creo que es bastante más cómodo.

¿Te asusta tu Air Wick?

Esta semana hemos comprado un ambientador Air Wick Freshmatic I-Motion, si si, un nombre muy rimbombante pero es que el aparatito se las trae, se trata de un ambientador en spray que se acciona automáticamente a intervalos de 9, 18 o 36 minutos pero la característica principal de este modelo, el I-Motion, es que lleva incorporado un sensor de movimiento de forma que cuando detecta que hay "alguien" cerca acciona el disparador dispersando la fragancia...

Es precisamente esto lo que hace que nos hayamos pegado unos cuantos sustos al entrar al aseo ya que, por lo general, uno entra al cuarto de baño sin demasiadas preocupaciones y no espera escuchar ningún ruido "extraño" pero desde que tenemos el Air Wick Freshmatic I-Motion cada vez que entramos el sensor de movimiento nos detecta y acciona el disparador lo que produce un sonido característico de sssssssssss que nos suele pillar por sorpresa.

Ya nos vamos acostumbrando pero los primeros dias fueron de lo más "curiosos" y es que al final pasa lo que pasa, en los anuncios de Air Wick los cuartos de baño que salen son inmensos y seguramente no se escuchará el disparador y todos felices y contentos pero cuando se pone este tipo de aparatitos en un aseo "normal" da hasta yuyu jeje.

Ah, por cierto, ya puestos a comentar cosas del Air Wick debo decir que, para mi gusto, es demasiado grande, tiene practicamente el tamaño de una botella de champú y como no se puede esconder ya que sino dejaria de ser util el sensor de movimiento pues hay que tenerlo casi en primera línea y desentona un poco pero en fin, es lo que hay, por lo menos la fragancia Nenuco es bastante agradable.

Actualización 26/11/2010
Recién hoy se han acabado las 3 pilas tipo AA que lleva. No esta mal para estar todo el día puesto. Han durado 5 meses.

Activar o desactivar un trigger en SQL

Esta mañana un amigo se ha encontrado con el problema de saber si un trigger se encuentra activado o no en SQL Server 2000 así que nos hemos puesto a googlear pero solo hemos encontrado información para activar o desactivar un trigger.

En SQL Server 2000 existen dos comandos T-SQL que permiten activar o desactiavar un trigger.

Activar un trigger

ALTER TABLE [nombre_tabla] ENABLE TRIGGER [nombre_triger]

Desactivar un trigger

ALTER TABLE [nombre_tabla] DISABLE TRIGGER [nombre_triger]

Pero ¿hay alguna forma de saber el estado actual de un trigger?, es decir, ¿podemos saber si el trigger se encuentra activado o desactivado?. SQL si debe almacenar esta información en algún sitio pero ¿donde?. La primera idea que se me pasó por la cabeza fué mirar en la tabla de sistema sysobjects, a fin de cuentas, un trigger es un objeto más de la base de datos, pero, aparentemente, ninguno de los campos de sysobjects hace referencia directa al estado del trigger y, en la ayuda sobre dicha tabla tampoco se menciona esta opción pero aún así vamos a hacer la prueba comprobando los valores de sysobjects antes y después de desactivar un trigger de forma que podamos ver si se produce algún cambio en la información.

Primero activamos el trigger (aunque se supone que debe estar activado ya que es el comportamiento por defecto cuando se crea un trigger) y luego hacemos la SELECT sobre sysobjects para ver que contiene.

Después desactivamos el trigger y volvemos a ejecutar la SELECT sobre sysobjects.

Podemos ver que solo ha cambiado el valor de la columna status así que parece ser que es en dicho campo donde SQL guarda la información sobre el estado del trigger (activado/desactivado) y, por el nombre, status, parece lógico pese a que en la documentación de sysobjects no se mencione nada al respecto.

Cuando el trigger estaba activado el valor de la columna status era 1610614528 y cuando lo desactivamos la columna status pasa a tener el valor 1610616576 ¿que significan estos valores? No hay mucha documentación sobre el campo status pero tiene toda la pinta de ser que es un campo "flag" donde se guarda información a nivel de bit sobre el estado de determinadas funciones así que vamos a pasar a binario los valores obtenidos.

1610614528 -> 1100000000000000000011100000000 (binario)

1610616576 -> 1100000000000000000111100000000 (binario)

Esto tiene buena pinta. En binario los dos valores son exactamente iguales a excepción de uno de los bits así que se puede suponer que ese bit es el que indica si el trigger esta desactivado o no. Cuando ese valor se encuentre a 1 indicará que el trigger está desactivado y cuando se encuentre a 0 indicará que el trigger está activado.

Si ponemos a cero todos los valores exepto el que nos interesa obtendremos la mascara que debemos validar para saber el estado de un trigger.

1610614528 -> 1100000000000000000011100000000 (binario)
1610616576 -> 1100000000000000000111100000000 (binario)
 (mascara) -> 0000000000000000000100000000000 (binario)
 (mascara) -> 0x800 (hexadecimal)

Por comodidad he pasado su valor a hexadecimal para montar una SELECT que nos indique el estado de nuestro trigger de ejemplo.

SELECT name, CASE WHEN status & 0x800 = 0 THEN 1 ELSE 0 END as TriggerActivado

FROM sysobjects WHERE name = 'miTrigger'

Hay que tener en cuenta que Microsoft dice expresamente que la columna status de la tabla sysobjects esta reservada a uso interno por lo que se supone que podrian modificar su funcionalidad sin previo aviso aunque, hasta la fecha, sigue manteniendo este comportamiento pese a que ya existen versiones superiores a SQL Server 2000.

Problema con mando compatible para Wii

La semana pasada compramos una Nintendo Wii, pero no voy a entrar en el debate sobre si es mejor una PS3 o una X-Box, para eso ya otros muchos blogs y foros, el motivo de este post es comentar el tema de los mandos compatibles para la Wii.

Cuando compramos la consola teniamos pensado utilizarla en pareja, es decir, buscar la mayor cantidad de títulos que nos dieran la posibilidad de jugar los dos (o más) al mismo tiempo pero uno de los principales problemas que te encuentras es que, por lo general, solo se incluye un mando así que te ves obligado a comprar otro adicional pero claro, después de hacer el desembolso de la consola pues "duele" tener que pagar casi 80 euros por el mando adicional.

Realmente el mando actual de la Wii lo forman tres accesorios, el mando principal (39.95€), el Nunchacu (19.95€) y el Motion Plus (19.95€), lo que hace la bonita suma de 79.85€

A estos tres accesorios hay que añadirle una "bonita" funda de silicona que suele venir incluida con el mando principal o con el Motion Plus.

Ahora ya conocemos los mandos de la Wii y tenemos claro que no queremos dejarnos 80 euros por lo que al ver que existen mandos compatibles se nos abren los ojos y es que resulta tentador ya que un pack de la marca Mad Catz con el mando principal y el Nunchacu cuesta 39.90€

Solo faltaría el Motion Plus pero para empezar a probar la consola ya nos damos por bien servidos.

Todo parecía ir bien hasta que jugando al Wii Sport Resort, concretamente a los bolos, una vecina se dio cuenta que ella nunca hacia plenos mientras que los demás participantes los hacian con bastante facilidad. Después de unas cuantas rondas nos dimos cuenta que siempre utilizaba el mando compatible así que decidimos cambiar y desde ese momento empezó a subir su puntuación y a hacer plenos.

Algo parecia fallar en el mando compatible, es como si no diera suficiente impulso, pense que tal vez fueran las pilas o que necesitase el Motion Plus pero le cambie las pilas, incluso le puse las pilas del mando original pero no dio resultado como tampoco dio resultado ponerle el Motion Plus de Nintendo así que, muy a nuestro pesar decidimos devolverlo, pasar por el aro y comprar los mandos originales.

Felizmente nos dimos una pequeña alegria al ver que Nintendo también habia sacado un pack con el mando principal y el Motion Plus por 49.95€ por lo que si añadimos los 19.95 del Nunchacu el total asciende a 69.90€. El ahorro no es tan espectacular pero algo es algo ¿no?

Solo falta decir que con el nuevo mando original si se consiguieron nuevos plenos en los bolos.

Con esto no quiero decir que todos los mandos compatibles tengan algún tipo de problema ni que los de Mad Catz lo tengan, simplemente pudo ser que el que nos tocó estaba defectuoso.

En DealExtreme también existen multitud de accesorios para Wii y entre ellos podemos encontrar el mando original con el Nunchacu y el Motion Plus.