Month: January 2011

Poniendo colores de fondo diferentes a diferentes elementos de un ComboBox

Los comboBox son un control que permite seleccionar uno (y solo uno) de una lista de elementos. Algunos lenguajes los nombran dropDownBox, en HTMl es una etiqueta SELECT, etc.

En la familia .NET, no existe forma “sencilla” (objeto.propiedad) de cambiar el color de fondo para diferentes elementos. Pero con un poquito de investigación, descubrí que es posible redefiniendo el método que se encarga de dibujar cada elemento de la lista, en el control. Esto se logra:

1. Modificando la propiedad DrawMode del control, de “Normal” a “OwnerDrawFixed” u “OwnerDrawVariable” (este último es útil si se quiere modificar el tamaño de los elementos, de otra forma Fixed nos funciona perfecto).

2. Agregando un método al evento DrawItem del control.

3. Poniendo en ese método algo como:

private void _DrawItem(object sender, DrawItemEventArgs e)
{
e.DrawBackground();
Graphics g = e.Graphics;
switch ()
{
case 0:
g.FillRectangle(new SolidBrush(Color.LightGreen), e.Bounds);
break;
case 4:
g.FillRectangle(new SolidBrush(Color.LightCoral), e.Bounds);
break;
case 8:
g.FillRectangle(new SolidBrush(Color.LightYellow), e.Bounds);
break;
case 12:
g.FillRectangle(new SolidBrush(Color.LightBlue), e.Bounds);
break;
default:
g.FillRectangle(new SolidBrush(Color.LightGray), e.Bounds);
break;
}
string text = ((ComboBox)sender).Items[e.Index].ToString();
Brush brush = Brushes.Black;
e.Graphics.DrawString(text, ((Control)sender).Font, brush, e.Bounds.X, e.Bounds.Y);
e.DrawFocusRectangle();
}

🙂

Cutler y el mito del “hombre de hierro”

A estas alturas, todos saben acerca de lo que pasó el domingo: Jay Cutler de los Osos de Chicago abandonó el partido en el tercer cuarto del campeonato de conferencia contra los Empacadores de Green Bay, abajo por 14 puntos, y esta salida fue subsecuentemente criticada sin piedad por los medios de comunicación, comentaristas, e incluso propios jugadores (y ex-jugadores) de la NFL.

Mi opinión, en resumen? Cutler no se lo merece. Pero alguien más lo expresa mucho mejor que yo:

http://youcantplayhere.blogspot.com/2011/01/when-lines-get-crossed.html

En esencia… eso del “jugador rudo” que aguanta lesiones y sigue jugando es fabuloso en teoría, pero en la práctica? Puede poner en riesgo tu salud – y en el caso de los jugadores profesionales, su vida, pues es su carrera en juego. *Suena* bonito, pero no es tan sencillo. Y evidentemente, cuando se critica sin saber las condiciones reales (nadie sabía en el momento que Cutler tenía su ligamento MCL roto), simplemente es ignorante…

Acerca de .Net, el manifiesto y los requisitos previos

Pues llevo la mejor parte de la noche (ok, ok, apenas un par de horas, pero es bastante para mí!) lidiando con un problema interesante. Explicaré un poco de los preeliminares, para que todos nos entendamos.

La plataforma de .Net es, para mi gusto, una verdadera maravilla. Si vas a desarrollar para Windows (y no te importa mucho obligar a tus usuarios a que instalen X dependencias que bien pueden ser molestas), te permite utilizar una serie de lenguajes muy parecidos entre sí, sólidos, con una gran base de desarrolladores que pueden ayudarte, código disponible en línea, e incluso bibliotecas listas para ser aprovechadas. Como Java, pues, pero sin la molestia de tener que usar… *eso*. Si tú desarrollaste en Visual Basic, VB.net es prácticamente lo mismo; si trabajaste en Java, C# es un camino bastante directo. Tiene gran versatilidad para desarrollar aplicaciones web, permite redistribución de dependencias (recuerden esto), tiene soporte para actualizaciones automáticas de tu aplicación… bueno, las bondades son demasiadas. En fin, es una plataforma que personalmente, me agrada bastante.

Nosotros, los programadores eventuales (es decir, que en realidad no nos dedicamos a esto para vivir), tenemos muchas malas mañas. Generamos código sucio, no muy organizado ni comentado; nuestra documentación puede catalogarse como garabateadas en servilletas y hojas de papel que acaban tiradas por ahí; y tendemos a vivir en el modo “debug”, nunca preocupándonos por cómo va a quedar la aplicación final cuando el usuario final decida instalarla – digo, podemos dejarlo hasta el final, no? El problema con esto es que cuando llega el famoso final… es una pesadilla.

De entrada, les recomiendo esto: no utilicen acentos para nombrar a su aplicación. No, .Net no truena con eso. Pero si quieren utilizar la funcionalidad de actualizaciones, su servidor web puede darse de topes con ustedes, porque va a buscar archivos y cadenas no fácilmente codificables. Solo… tómenlo como una recomendación amable.

Y por supuesto, el centro del problema: los requisitos previos. .Net corre sobre una máquina virtual (el “Framework”), y mi aplicación en particular utiliza un motor de bases de datos sencillo (SQL Server CE, que es algo así como el primo debilucho de SQL Server Express, que a su vez es el babas a comparación de SQL Server, que a su vez… etc etc), comparable con sqlite. El Framework, para instalarle, utiliza *otro* requisito previo, el Windows Installer (v.3.1 en este caso en particular). Estos requisitos son manejados elegantemente por el instalador generado por .Net: se descargan automáticamente de internet, si el usuario final no los tiene ya instalados. El problema es que, combinados, son alrededor de 100 Mb de descarga: ciertamente no es mucho para un geek, pero un usuario con una conexión de Infinitum a 512 (cuando le va bien) nos va a obligar a visitar a los papás. So… debemos poder incrustarlos con nuestro instalador, cierto?

La respuesta es “sí, pero te va a costar trabajo”. Resulta que estos instaladores (que se pueden bajar bastante fácil de internet) no se ponen en cualquier localidad. Deben ir en el directorio que .Net utiliza para almacenar los instaladores. Suena sencillo… hasta que nos enteramos que cada versión del Framework tiene diferentes localidades (y lo mismo para cada versión del Installer, SQL, etc), y que a su vez, cada versión de la IDE lo pone en directorios ligeramente diferentes. En mi caso?

C:Program Files (x86)Microsoft SDKsWindowsv7.0ABootstrapperPackages

¬¬ Sí te iba a encontrar, no?

Pero gracias a un valiente y hermoso post:

http://social.msdn.microsoft.com/forums/en-US/Vsexpressvb/thread/56584721-3064-46c2-81f4-6c29c01e1895/

Tuvo solución el problema. La moraleja, como siempre, es no fiarse de M$.

😀