Iconos e imágenes en Wisej.NET

Iconos e imágenes en Wisej.NET, módulo uno. Wisej.NET ofrece varias formas de poner una imagen en un control, así que la primera decisión de este curso siempre es qué mecanismo es dueño de la imagen.

La propiedad Image guarda un System.Drawing.Image que el servidor mantiene en memoria y envía al navegador como PNG. ImageSource guarda solo una cadena, así que en el servidor no se decodifica nada. Las dos llenan el mismo hueco visual del control, y por eso la elección tiene que ser deliberada.

Esa cadena puede ser una URL relativa, una URL absoluta, una imagen de tema con nombre o una ruta resource.wx, y es el cliente quien la resuelve. Los controles capaces de mostrar imágenes comparten un mismo contrato a través de IImage, así que un botón, una etiqueta y una celda de cuadrícula exponen la misma familia de propiedades de imagen.

En IconDesk, el botón Open recibe un objeto de imagen que el servidor lee de un archivo. El botón Save recibe el nombre de una imagen de tema en ImageSource. Print y Delete comparten un mismo ImageList y eligen su dibujo por clave, así que es la lista la que decide qué dibujan esos dos botones.

Un ImageList es indirección más que almacenamiento. Una clave transmite un significado que sobrevive a los reordenamientos, mientras que un índice es solo una posición y pasa a apuntar en silencio a otro dibujo en cuanto la colección cambia. Sustituye la imagen guardada bajo una clave y todos los controles que la usan la siguen, sin tocar ninguna otra línea de código.

La etiqueta de diagnóstico le pregunta a cada botón, a través de IImage, qué propiedad de imagen está realmente rellena. Esa pregunta atrapa un fallo habitual: un origen de imagen asignado después de una clave de imagen se queda con el hueco, la clave sigue puesta y el control dibuja la cadena. Leer el control es mejor que adivinar.

Al ejecutar la página, cuatro iconos llegan por cuatro rutas distintas y todos se ven igual de correctos. Solo el botón Open obligó al servidor a decodificar una imagen; los otros tres los resolvió el navegador. La etiqueta nombra el mecanismo que hay detrás de cada uno, así que la diferencia se ve en lugar de suponerse.

Sustituir el dibujo que hay detrás de la clave delete actualiza ese botón por sí solo, porque el control se refiere a la clave y no a la imagen. Asignar después un origen de imagen a ese mismo botón cambia lo que dibuja, mientras la clave sigue puesta y se ignora.

Laboratorio uno: construye el panel de comandos de IconDesk con los tres mecanismos, añade la etiqueta de diagnóstico que lee cada botón a través de IImage y anota qué hicieron de verdad el cambio de clave y la doble asignación.

Módulo dos. La página ImageLab de IconDesk pone un objeto de imagen y una cadena de origen de imagen lado a lado sobre controles PictureBox, para que la diferencia entre las dos canalizaciones sea algo que puedas ver.

Preguntar qué formatos admite Wisej.NET no tiene una única respuesta, y tratarla como si la tuviera provoca fallos reales. Un logotipo estirado y deformado, una página que se queda bloqueada mientras se descarga una fotografía remota y un archivo de icono que se niega a cargar nacen todos de juntar dos listas de formatos en una sola.

Mantén las listas separadas. Mapa de bits, Metafile, icono, JPEG, GIF y PNG viajan por System.Drawing y la propiedad Image. El controlador de recursos y las imágenes de tema aceptan como cadenas JPEG, PNG, GIF, SVG y mapa de bits. El SVG pertenece a la canalización de cadenas; no es un formato de System.Drawing.

Seis modos de tamaño describen qué pasa cuando la imagen y la caja no coinciden. Normal corta lo que no cabe, AutoSize ajusta la caja a la imagen, CenterImage la centra, StretchImage la deforma, Zoom encaja la imagen entera dentro y Cover llena la caja y recorta lo que sobra.

Cuatro controles comparten una misma cadena de origen y solo se diferencian en el modo de tamaño, lo que aísla la decisión de tamaño de la decisión de carga. El archivo de icono heredado pasa de la cadena de origen a la propiedad Image, porque icono y Metafile pertenecen a la canalización de System.Drawing.

LoadAsync trae la foto del socio sin bloquear la página mientras llega. Un único icono vectorial, direccionado como cadena de recurso, alimenta cuatro tamaños distintos desde el mismo recurso. Después, un manejador de informe imprime, para cada PictureBox, si la imagen vino de Image o de ImageSource.

Al ejecutarla, el mismo recurso queda cortado por Normal, encajado por Zoom, recortado por Cover y aplastado por StretchImage. La foto remota todavía viene en camino y la página sigue siendo usable mientras se descarga, que es justo el sentido de cargarla de forma asíncrona.

La fila vectorial se mantiene nítida a dieciséis, veinticuatro, treinta y dos y cuarenta y ocho píxeles. El mapa de bits pequeño ya se ve borroso a treinta y dos, porque el navegador está agrandando píxeles que nunca existieron. El informe nombra después la canalización que hay detrás de cada control, así que nadie tiene que adivinar.

Laboratorio dos: construye ImageLab con cuatro modos de tamaño sobre un recurso ráster, una foto remota mediante LoadAsync, un icono vectorial en cuatro tamaños, el manejador de informe y la nota sobre formatos.

Iconos e imágenes, módulo tres. La imagen de un control muchas veces no es un archivo que envías junto a la página, sino una cadena de origen, y la pantalla IconGallery llena cinco huecos de cinco maneras distintas.

El módulo dos dejó IconDesk con una ruta escrita a mano para cada aspecto, lo cual está bien hasta que el aspecto tiene que cambiar. Un tema puede aportar la imagen como URL relativa, como URL absoluta, como datos incrustados o como imagen con nombre, y solo la imagen con nombre añade una capa de indirección.

Asignar el nombre de una imagen de tema a ImageSource no abre ningún archivo ni crea ningún System.Drawing.Image. El nombre es una clave que el cliente resuelve desde el tema que ya tiene cargado, y por eso otro tema puede aportar otro dibujo sin cambiar ni una línea de tu código C#.

El Selector de imágenes del diseñador recorre las imágenes del proyecto, las imágenes de tema y todos los packs de iconos a los que el proyecto hace referencia, con una vista previa de cada una. Para los iconos monocromos también previsualiza el color, así que la decisión de recolorear se toma mirando y no recompilando y recargando.

Lee lo que escribió el selector. Designer.cs guarda una cadena de origen de recurso que apunta al ensamblado que contiene el dibujo, nunca una copia del archivo. Esa misma cadena se puede calcular en tiempo de ejecución, lo que importa cuando el icono depende del estado y no del diseño.

Añadir el sufijo de color a una cadena de origen recolorea un icono vectorial monocromo apto. Un color literal funciona, pero es mejor un nombre de color de tema, porque así el icono sigue al tema en lugar de fijar un valor que un cambio de paleta futuro contradirá en silencio.

Al ejecutar IconGallery, cinco huecos se llenan con una clave de tema, una URL relativa, una URL absoluta, un recurso de pack y un icono vectorial recoloreado. Parecen igual de asentados, pero solo la URL absoluta depende de un servidor que tú no controlas, y eso conviene saberlo antes del despliegue.

Ahora cambia de tema. La clave de tema resuelve a un dibujo nuevo y el color de tema nombrado en el sufijo cambia con él. Los tres orígenes que nombraban un dibujo exacto siguen idénticos, y esa es la diferencia práctica entre una referencia semántica y una literal.

Laboratorio tres: llena IconGallery con el Selector de imágenes, recolorea un icono monocromo con un nombre de color de tema, lee las cadenas de Designer.cs y escribe la nota sobre el cambio de tema.

Módulo cuatro. IconDesk necesita cinco iconos hoy y quizá cuarenta más este trimestre. Reunirlos archivo a archivo te deja varios grosores de trazo, ningún estilo común y ningún registro de dónde salió cada uno.

Un pack de iconos es un ensamblado .NET normal cuyos dibujos se guardan como recursos incrustados. Un solo archivo en la carpeta de salida puede llevar cientos o miles de iconos, y cada uno se sigue direccionando por separado a través del controlador de recursos, así que nada queda empaquetado en un bloque inservible.

Los dos mecanismos entregan de forma distinta, y eso decide dónde encaja cada uno. Los iconos de un pack se piden bajo demanda: una petición la primera vez que se usa el icono y después la caché del navegador. Las imágenes de tema se envían por adelantado, precargadas junto con el tema, y por eso los catálogos muy grandes van en un pack.

Instala los packs desde los paquetes oficiales de Wisej-4 y mantén sus versiones mayores alineadas con las del framework. Después compila el proyecto antes de buscarlos, porque el explorador de imágenes solo lista los packs contra los que el proyecto ya ha compilado.

Elige un icono y lee lo que generó el diseñador: el controlador de recursos, el ensamblado del pack, el archivo del icono y, de forma opcional, el sufijo de color. Cada parte de esa cadena se comprueba en tiempo de ejecución, y por eso un nombre de archivo escrito de memoria no resuelve a nada.

En C#, prefiere el catálogo de iconos del pack antes que una cadena escrita a mano, para que un cambio de nombre sea un error del compilador y no un control en blanco. El espacio de nombres exacto varía de un pack a otro. Asigna una sola propiedad de imagen por control y deja un texto junto a cualquier icono que transmita significado.

La página IconCompare muestra los mismos cinco conceptos dibujados por dos familias, y eso hace evidente la diferencia de estilo como nunca lo hará una página de catálogo. Dos iconos monocromos aceptan el sufijo de color con un nombre de color de tema; los dibujos de varios colores simplemente lo ignoran.

El panel de red aporta la evidencia: una petición por icono en la primera carga y aciertos de caché al recargar. Una recomendación respaldada por eso se puede defender, y además muestra por qué referenciar un pack grande no le cuesta al usuario una descarga grande.

Laboratorio cuatro: referencia dos packs de Wisej-4, construye con ambos una página IconCompare, elige al menos cinco iconos en el explorador, recolorea dos y nombra la familia de iconos principal del proyecto.

Iconos e imágenes, módulo cinco. Cinco recursos de IconDesk dejan de ser archivos sueltos junto a la aplicación y pasan a viajar dentro del ensamblado, direccionados por una cadena en lugar de por una ruta en disco.

Un dibujo desplegado junto a la aplicación está a un paso de copia olvidado de quedarse roto. El servidor responde que no lo encuentra, el control no dibuja nada y el archivo sigue estando en la máquina del desarrollador, y por eso el problema suele sobrevivir hasta que otra persona ejecuta la compilación.

Para esto no hay API. Añade el archivo al proyecto y pon su Build Action en Embedded Resource, y los bytes pasan al manifiesto del ensamblado. Esa única propiedad es también lo que convierte una biblioteca de clases normal en un pack de iconos, como verás en el módulo seis.

Direcciona el recurso como una cadena. Sin nombre de ensamblado, Wisej.NET busca un recurso coincidente entre los ensamblados cargados. Nombrar el ensamblado de forma explícita, escrito sin la extensión del archivo, elimina la ambigüedad cuando dos ensamblados podrían contener cada uno un archivo con el mismo nombre.

El controlador sirve exactamente nueve extensiones: hojas de estilo, scripts, HTML, JPEG en sus dos grafías, PNG, GIF, gráficos vectoriales y mapas de bits. No sirve nada más, así que un archivo de icono incrustado con mucha ilusión sigue siendo un no encontrado, y la solución es convertirlo y no depurar la URL.

Un archivo desplegado con la aplicación puede responder a esa misma dirección antes que la copia incrustada. Eso resulta muy útil para el cambio de marca de un cliente o para un arreglo urgente sin recompilar, y también significa que la carpeta que guarda esas sobrescrituras es ahora algo que tienes que proteger.

En el navegador, cinco peticiones devuelven cinco respuestas correctas, todas servidas desde el ensamblado de la aplicación, y la recarga llega ya desde la caché. El dibujo vectorial sigue siendo marcado de principio a fin; en ningún momento se convierte en una imagen de System.Drawing.

Dejar un logotipo de reemplazo junto a la aplicación desplegada cambia la imagen sin recompilar nada. Después, una letra duplicada en el nombre de un recurso produce un no encontrado, y la lista de seis pasos lo localiza en el paso cuatro, que es más rápido que volver a leer el código.

Laboratorio cinco: incrusta cinco recursos, muéstralos todos en ResourceLab, califica un origen con el nombre del ensamblado, sobrescribe uno con un archivo desplegado y documenta la caza del no encontrado.

Módulo seis. IconDesk ya usa iconos por todas partes y no es dueño de ninguno. El remedio es un pack propio: una biblioteca de clases, un directorio Resources y doce iconos vectoriales marcados como recursos incrustados.

Ahora mismo el mismo icono está escrito de cuatro maneras ligeramente distintas en cuatro pantallas. Cada una de esas rutas es una cadena, así que tres compilan perfectamente y solo fallan en el navegador, lo que traslada el error de la compilación a la pantalla de un cliente.

La receta documentada tiene cuatro pasos: crea una biblioteca de clases, crea un directorio Resources, pon los iconos dentro y establece su Build Action en Embedded Resource. Lo que sale es una dirección formada por el controlador, el nombre del ensamblado y la ruta del recurso. Confírmala una vez contra la aplicación en ejecución.

El catálogo convierte esa dirección en IntelliSense. Una constante privada guarda la parte común de la ruta y una constante pública por icono nombra el concepto y no el archivo, así que quien lo use escribe un nombre de producto como Save o Warning en lugar de repetir una ruta.

Dos caminos terminan en la misma cadena. El Selector de imágenes la escribe en Designer.cs cuando el icono lo decide el diseño, y el código en ejecución la lee del catálogo cuando lo decide el estado de la aplicación. Y el dibujo vectorial sigue siendo marcado que resuelve el cliente, nunca una imagen de System.Drawing.

Funciona. Doce iconos vienen de un único ensamblado referenciado, llegan de petición en petición según se usa cada uno por primera vez y se sirven desde la caché del navegador en la siguiente carga. Nada de la aplicación necesitó saber dónde vive el dibujo en el disco.

El sufijo de color recolorea dos iconos y el tercero lo ignora, porque ese archivo lleva un color fijo dentro del dibujo. Quita ese valor fijo del marcado y comprueba después el resultado en un tema oscuro, en lugar de dar por hecho que el arreglo se mantiene.

Tres hábitos mantienen el pack sostenible: un concepto por icono, el catálogo tratado como la API pública del pack para que renombrar siga siendo asunto del compilador, y una ruta de sobrescritura documentada para la aplicación que necesita otro dibujo bajo el mismo nombre de siempre.

Laboratorio seis: construye la biblioteca IconDesk.Icons con doce iconos incrustados y el catálogo, asigna unos en el diseñador y otros desde código, comprueba tres recoloreados y escribe las reglas de versionado.

Iconos e imágenes en Wisej.NET, módulo siete, el proyecto final. IconDesk ya sabe dibujar un icono de cinco maneras distintas. Ahora gana una sexta y, más importante, la regla escrita que decide entre ellas.

Un objeto de imagen, una cadena de origen de imagen, una imagen de tema, un recurso incrustado y ahora una fuente de iconos. Seis mecanismos sin una primera opción escrita son la razón de que el mismo comando Delete acabe viéndose distinto en tres pantallas de la misma aplicación.

Una fuente de iconos se salta por completo la canalización de imágenes. Un enlace a la hoja de estilos en el Default.html de la aplicación permite que el navegador descargue el CSS y los archivos de fuente, y una clase CSS puesta dentro del texto de un control que admite HTML dibuja el glifo como un carácter.

Ningún enfoque gana de forma rotunda. Los recursos de Wisej aportan el recoloreado, el Selector de imágenes y propiedades de imagen de verdad. Las fuentes aportan un sistema de diseño CSS que ya existe y dejan que el glifo vaya en línea con el texto. Que esa hoja de estilos venga de una red pública o de tu propio servidor es una decisión real.

En el código, las dos decisiones están en niveles distintos. El enlace a la hoja de estilos es una decisión de toda la página; permitir HTML es una decisión por control que tomas de forma deliberada. Dos glifos con papeles distintos pueden entonces compartir una misma celda de cuadrícula, y el clic informa de qué elemento se pulsó realmente.

Esta es la política. Imágenes de tema para los dibujos semánticos que siguen al tema. Un pack principal para los comandos. El pack propio para los dibujos de producto que son tuyos. Formatos ráster para las fotografías. Fuentes de iconos solo donde la integración con HTML compense de verdad la dependencia extra.

La página de resumen ejecuta los cinco mecanismos a la vez. Cambia el tema y solo lo siguen la imagen de tema y el icono vectorial recoloreado. El icono del pack, el icono del pack propio y el recurso incrustado se quedan exactamente como estaban, y ese es el comportamiento sobre el que está escrita la política.

La columna de acciones responde a dos clics distintos desde una sola celda leyendo el papel del elemento pulsado. Después la revisión de calidad se repite en un tema oscuro, comprobando que cada glifo sigue siendo legible y que cada acción sigue llevando un nombre que un lector de pantalla pueda anunciar.

El proyecto final: la hoja de estilos y una barra de herramientas que admite HTML, la columna de cuadrícula que conoce los papeles, la página de resumen que cubre cinco mecanismos, la política de iconos escrita y una nota de calidad en tema claro y oscuro.