Algunos bugs del Compact Framework

No llevo ni mil líneas de código de un nuevo proyecto embebido en C# y ya me he encontrado con al menos cinco bugs. En su momento abandoné C# para escritorio porque era un juguetito que apenas daba de sí para realizar aplicaciones de sistemas medianamente complejas. El mayor problema estribaba en que como te salieras de lo que los sabios habían determinado, aquello no funcionaba ni para atrás. Cosas que fallaban, muchas. Las más flagrantes eran serios problemas con los constructores estáticos, agravados en el caso de que se produjera una excepción dentro de ellos, excepciones que no se lanzaban cuando debían, y un largo etcétera en relación a elementos de Windows Forms.

Tengo constancia de que muchos de esos problemas han sido solucionados con los distintos Service Packs que le han ido saliendo a la versión 2.0 del .NET Framework, y pensaba que ya que el Compact también lleva unos cuantos, no tendría problemas con él.

Pero no es así en relación al Compact. Fijaros que no estoy hablando del 3, ni del 3.5, sino del 2.0, que lleva una buena porrada de años en la calle y que ya debería funcionar medianamente bien. No quiero yo ver la porquería que serán el 3 y 3.5 (recuerdo haber encontrado y reportado 5 bugs en una única sesión de media hora de jugar con ellos, de los cuales la mayoría serían resueltos en next version, que es la forma políticamente correcta que tiene Microsoft de quitarse a los pesados de encima y decirte con buenas palabras que no lo van a solucionar).

Los más triviales del Compact 2.0 se encadenan en torno al componente Tab Control, y básicamente tienen que ver con el tamaño del mismo y la posición de las páginas. Hablamos del .NET Compact Framework 2.0 con todos sus parches en compilación AnyCPU, no de la versión de escritorio.

Cuando el componente es más grande que la ficha y sale por debajo porque está anclado por arriba a la misma, .NET dibuja una barra de desplazamiento vertical que permite contener el componente completo. Sin embargo, si la anclamos por debajo, la barra de desplazamiento no aparece, y entonces los controles que haya en la parte superior ocultos a la vista no serán visibles.

El siguiente también tiene relación con este, y se presenta de forma aleatoria (o al menos yo no he sido capaz de poder reproducirlo siempre). El control no se redimensiona. Ya puedes ponerle el Width o el Heigth al valor que quieras, que él seguirá con el que tenga en tiempo de diseño. Parece estar relacionado también con el tipo de anclaje y de dock, pero no estoy seguro.

El gordo. Este problema clama al cielo, es para llorar, ya veréis. Crea un proyecto embebido en C# para Windows CE con el asistente y para el Compact 2.0. Añade un PictureBox al Form. Clica en la propiedad Image y carga un fichero JPG. Una vez hecho esto deberemos estar viendo la imagen en tiempo de diseño. Ejecutemos sobre un emulador o sobre un dispositivo real.

¡Tachán! Excepción al canto, la imagen no aparece por ningún lado. Os adjunto una imagen, para que veáis que no hay trampa ni cartón:

image

A la izquierda está el editor abierto por la excepción y mostrando esta, del tipo “Exception”. A la derecha está el Form mostrando la imagen, y más a la derecha el emulador.

Para más inri y jocosidad (aunque es para llorar), el tipo de excepción es “Exception”, así, a pelo. No del tipo recurso no encontrado, ni fichero no encontrado, ni nada de eso. Simplemente una “excepción”.

Pero todavía hay más, porque al menos en Windows CE te salta la excepción, en Windows Mobile, por ejemplo, simplemente falla, sin disparar ningún tipo de excepción ni nada.

No os vayáis, porque ¡sí, hay más!: incluso poniéndola a mano como un recurso normal, luego en el ejecutable ¡no hay imagen! Es decir, que lo que quiera que haga de linker en el C# pasa olímpicamente de este tipo de recurso.

¿Es para llorar o no? Pues eso, que se le quitan a uno las ganas.

V2.0

Bueno, lo de arriba fue escrito y programado para que se publicara el 21 de abril, ya que tengo entradas preparadas hasta esa fecha, pero resulta que mientras llega el citado día, seguí con el tema a ratos, porque no es un proyecto del curro, sino personal. Si lo contado hasta ahora clama al cielo, no os digo ya lo que viene a continuación.

Unos días después de desistir con el tema, vi el dispostivo con Windows CE por encima de la mesa y me dije que iba a reintentarlo, y así lo hice. Conecté el aparato (un JE200 vuelto a convertir en un cacharro CE puro para los curiosos) y para escarnio y befa personal, ¡funcionó a la primera! Bueno, no realmente, porque para evitarme la descarga de todo el Compact sobre el dispositivo, y sabiendo que él traía ya una versión 2.0, desconecté la opción de cargar siempre la última versión en el aparato/emulador.

Y entonces funcionó. O en otras palabras, la imagen se embebió en el ejecutable y este funcionó perfectamente. No obstante, había ahora un nuevo problema: el color de fondo de los botones no se cambiaba por el que yo había decidido (suma bug y sigue).

Me da por probar en un emulador de Windows Mobile 2003 y funciona todo perfecto, incluso lo de los botones. De vuelta al emulador del CE, me dice que el .NET instalado es muy viejo. ¿Cómo que muy viejo? Si lo que pasa es que no hay .NET (Si lo sabré yo que . Otro más al cesto.

Para resolver lo anterior, reactivo lo de bajar la última versión del Compact, lo hizo, cargó y funcionó, aunque el tema de los botones siguió sin funcionar… Lo cierto es que funcionó sólo la primera carga. En la demás ya dejó de hacerlo. Suma y sigue.

Bueno, al final, resumiendo: tras al menos dos Service Packs y varias “actualizaciones de seguridad”, el Compact no sólo es la misma mierd@ que antes, si no incluso peor, con regresiones que ni siquiera estaban presentes en la RTM.

Personalmente se me cae la cara de vergüenza ajena con esto, lo que reafirma y confirma algo que he dicho por aquí no hace poco: los test no valen para nada. Y me da para otra entrada sobre este tema que ya estoy empezando a barruntar. Permaneced atentos.

4 comentarios sobre “Algunos bugs del Compact Framework”

  1. Hola Rafael, en defensa del CF he de decir que estuve unos cuantos años peleando con él, desde la versión 1.0 hasta la última y ni de lejos encontré todos los bugs que encontraste en menos de 1000 lineas. hombre, tiene sus cosillas, sí, pero tampoco es el anticristo. hay algunas cosas que apuntas que son meras limitaciones -historicas por cierto- del CF como lo del color de los botones.

    saludos

  2. Pero lo que más me jode es que no esté documentado. Si al menos en la documentación dijera que esto o aquello no se pudiera hacer…

    De todos modos, si son limitaciones, que no las pongan como posibles.

    Es como el cuentaquilómetros de mi coche: pone 190… pero no pasa de 140 cuesta abajo y con el aire a favor…

    Pues que pongan 140, ¿no?

  3. Por descontado que la documentación brilla por su ausencia y tenias que ver en las primeras versiones con WiMo 2003 y si eres asiduo de WinCE ya ni te cuento, no tiene ni pocket outlook ni connection manager etc…, solucion P/Invoking y además capado. De hecho las librerias OpenNETCF surgieron de esa necesidad. Si además contamos los 3 años que Microsoft ha estado pasando de .NET CF y centrandose en el nuevo model de desarrrollo de WiPhone 7 ya lo tenemos todo vendido.

    Ah! y los cuentaquilometro tiene su explicación. Es para abaratar costes (para ellos claro -los fabricantes-) 😉

  4. Madre mía qué somanta de ostias en un momento contra todo el equipo de desarrollo no ya de .NETCF sino de la Framework en general!

    Eres como el tío la vara pero en versión developer xDD

Responder a jmtorres Cancelar respuesta

Tu dirección de correo electrónico no será publicada. Los campos obligatorios están marcados con *