windows – El que mucho abarca

De C#, y porqué el tamaño sí importa

Resúltose que estabamos probando una mejora a la aplicación de Factúralo tú mismo, cuando nos hablaron para una solicitud de soporte… algo extraña.

En todos los sistemas que habíamos probado la aplicación, esta nueva actualización se realizó sin problemas. Era una actualización, a decir verdad, mucho más estética que de funcionalidad: se cambió un poco el look de la aplicación, para que fuera más concordante con los estándares de UI actuales (digamos, íconos más bonitos, etc). Pero bueno, a uno de nuestros usuarios, este movimiento le causo el siguiente horror:

************** Texto de la excepción **************


System.ComponentModel.Win32Exception (0x80004005): El parámetro no es correcto
   en System.Drawing.Icon.Initialize(Int32 width, Int32 height)

en System.Drawing.Icon..ctor(SerializationInfo info, StreamingContext context)

La absoluta irreproducibilidad del error (y que se note que lo intenté, en los 3 equipos de los que pude echar mano el fin de semana) me llevó a considerar el problema un *extraño* más, y dejarlo como otro caso para la araña. Sin embargo, hoy me hablaron diciendo que el caso se había esparcido – sí, es correcto – a otro equipo de cómputo. La única característica definitoria para ambos? Netbooks.

Pues me puse a investigar. Evidentemente el problema hacía alusión a íconos, pero… a cúales? Ay de mí si eran los que había agregado… tendría que deshacer el trabajo de la semana. Pero sin desánimo me puse a buscar, y al final resultó ser el ícono de la aplicación. Sí, un simple ícono… con los siguientes parámetros:

WIDTH:700
HEIGHT:699

¬¬ Ok, eso podría ser. Pero porqué los demás sistemas se actualizaban sin problemas? Aparentemente, hay versiones de Windows que ejercen de manera más estricta el tamaño de los íconos – o mejor dicho, Vista/7 se ajustan dinámicamente aunque les avientes una barbaridad como aquella, y lo redimensionan automáticamente.

Algo nuevo aprendí hoy XD

Cómo utilizar DLLs externos en un programa de C#

…Después de la catarsis…

Hace poquito escribí acerca de mi alegría en obtener una rápida y eficiente solución a un problema que me estaba preocupando, específicamente de cómo copiar de manera segura archivos utilizando C#. Me encontré una biblioteca que hace justamente eso, utilizando el buen y viejo SCP. En pruebas todo estaba bien, terminé otras actualizaciones al proyecto, y como siempre, lo subí a un servidor donde la versión más nueva es descargable por los usuarios del sistema (o en resumen: “actualicé el servidor de actualizaciones”).

…Y que me avisan – esto no sirve. Terriblemente apenado, revisé inmediatamente la situación (ERT: 10 mins) y descubrí que C# me mostraba un error horrible a la hora de querer actualizar:

"[...]El archivo XXXX ya existe."

Mmm… huh? Pues claro que ya existe, babas. Era uno de los archivos .DLL que agregué para utilizar su funcionamiento. Pero… porqué se quejaba el instalador de ello?

La moraleja en versión breve es: lo agregué dos veces. Primero lo agregué como archivo al proyecto (Proyecto | | Incluir recurso existente) y luego agregué la referencia (Referencias | Agregar referencia). El manifiesto se confundió y chilló sin tregua.

Lección aprendida: Si vas a agregar un DLL externo, solo tienes que agregarlo como referencia. No es necesario agregarlo como archivo – Visual Studio se encarga de incluirlo con tu proyecto en el deployment.

Extraer nombres de rutinas en códigos fuente tipo C

Bien dicen que la necesidad es la madre de la invención.

Tenía que extraer todos los nombres de rutinas de las diferentes clases de C# que he estado trabajando. Después de buscar en Visual Studio por alguna opción que me permitiera hacer esto de manera sencilla – y vaya que busqué – me desesperé y pensé… finalmente son texto plano, no? Las clases, esto es.

Pues, ¡claro que lo son! Y entonces awk viene muy al caso. El siguiente script sirve para cualquier código fuente tipo C (rutinas con parámetros entre paréntesis, código de la rutina entre llaves) – siempre y cuando las llaves no estén nunca en la misma línea que el nombre de la rutina (una práctica relativamente común). Ejemplo de lo que sirve:

modificador modificador RUTINA(parámetros si los hay) { ... }

o también

modificador modificador RUTINA(parámetros si los hay) {...}

o cualquier combinación entre ellas. Luego entonces, el script:

awk 'BEGIN{x=0;} {if($0 ~ /{/) x=x+1; if($0 ~ /}/) x=x-1; if(x==0 && $0 !~ /}/) print $0;}'

Nótese que esto no nos quita los modificadores, solo el código intermedio. Si queremos quitar todo lo demás, podemos utilizar sed – pero después de 10 minutos de jugar con él me doy cuenta que no es trivial (al menos ahorita ¬¬) y lo dejo para otro post – o como dijeran mis libros de la prepa: “Queda como ejercicio para el lector”.

🙂

Messenger 2011, Tweetdeck, y mi CPU: el asesino (no tan) silencioso

Como aquellos que me conocen saben, tengo una cierta costumbre de trabajar de noche. Es fabuloso para mí: nadie me molesta, no molesto a nadie (salvo por el ruido del teclado), avanzo muy rápido, la red está especialmente fluida… todo conspira para que sea mi horario de facto. Evidentemente, como me encanta la música, suelo traer puestos mis audífonos – los muy fantásticos MDR-NC7 de Sony, altamente recomendados por cierto – y evidentemente no escucho absolutamente nada de lo ocurre afuera.

Por ello, no me dí cuenta del problema inmediatamente.

Hoy en la tarde noté que tenía mucho calor. Esto es anormal en mi cuarto: desde que sergiob se mudó a Amazon, no existe un equipo de cómputo con su CPU al 100% todo el tiempo (y por ende, con ventiladores a máximo), lo que reduce muchísimo la temperatura – sin mencionar el gasto de luz eléctrica. Pero recuerdo bien la sensación… total que encontré las mismas condiciones, y me sorprendió mucho. Tenía la televisión prendida, y bueno, no me dí cuenta al inicio que los ventiladores zumbaban al máximo, prácticamente gritando “wey! Pon atención!” Llegó la noche y el calor continuaba. Con los audífonos, el ruido hubiera sido evidente – pero, afortunadamente, Elena marcó por teléfono. Y esto me forzó a quitarme los audífonos, a escuchar el ambiente… y a notar el tremendo ruido que causaba mi compu. Windows no viene con un monitor de recursos incrustable en la barra de tareas – como lo permite GNOME – de manera que no puedo echarle un ojo permanente a los recursos. OK, pero no es culpa de Windows, enteramente.

Un rápido vistazo al administrador de recursos dió con 3 aplicaciones que, alternadamente, se jugaban entre el 25% y el %60 de mi procesador. El primero es iTunes: viejo conocido de los problemas de CPU. El segundo fue Tweetdeck: entendible en que es Beta, aunque… qué demonios tiene que ocupar tanto CPU una estúpida aplicación que en resumen es un RSS reader? Ah, las maravillas de Adobe Air. El tercero, sin embargo, me sorprendió tremendamente: Windows Live Messenger.

Así es. El ubicuo mensajero, que solía ser de los programas menos demandantes (algo que contribuyó tremendamente a su adopción generalizada, por cierto – aquellos usuarios de Yahoo! Messenger o ICQ en los viejos días sabrán a lo que me refiero) – ahora resulta que es un hoyo negro para los recursos de mi sistema. Una ligera investigación reportó que, efectivamente, WLM 11 tiene un grave problema de recursos – relacionado con la “Vista completa”, donde permite recabar información de diferentes redes sociales. Al parecer, esta tarea acosa terriblemente al procesador, causando picos constantes que, a la larga, conllevan un aumento de temperatura, y todos los problemas que esto último ocasiona.

La mejor solución? Cambiar a “Vista compacta”. Por supuesto que se pierde el componente de redes sociales: pero francamente, prefiero enterarme de algo por las alertas del correo de Facebook, a que mi compu se muera prematuramente. El calor es un terrible asesino, como cualquier persona involucrada en soporte técnico puede asegurarles. Terriblemente efectivo, y lamentablemente fácil de evitar – si estamos dispuestos a controlarlo. Es por ello que me encanta mi panel de monitoreo en Debian, es por ello que pagaría buen dinero por un panel similar en Windows. Realmente lo vale.

Un último tip: otro posible problema de WLM 11 son los anuncios. Un anuncio mal programado (y créanme, los hay) puede inducir el mismo comportamiento excesivo de recursos. Así que ya lo saben: poco y bueno con el Messenger.

A veces se me olvida lo lindo que es Visual Studio…

private void algunTextbox_KeyPress(object sender, KeyPressEventArgs e)
{
const char Delete = (char)8;
e.Handled = !Char.IsDigit(e.KeyChar) && e.KeyChar != Delete;
}

🙂

P.D.: Esto sirve para que, con C# (o bien, C sharp), podamos limitar el contenido de un textbox a solo digitos. En esencia, estamos aceptando teclazos si y solo si son digitos (o estamos borrando).