Icônes et images dans Wisej.NET

Icônes et images dans Wisej.NET, module 1. Wisej.NET propose plusieurs façons de poser une image sur un contrôle : la première décision de ce cours est donc toujours de savoir quel mécanisme possède l’image.

La propriété Image porte un System.Drawing.Image que le serveur garde en mémoire et envoie au navigateur en PNG. ImageSource ne porte qu’une chaîne, donc rien n’est décodé côté serveur. Les deux remplissent le même emplacement visuel du contrôle, et c’est précisément pour cela que le choix doit être délibéré.

Cette chaîne peut être une URL relative, une URL absolue, un nom d’image de thème ou un chemin resource.wx, et c’est le client qui la résout. Les contrôles porteurs d’image partagent un même contrat via IImage : un bouton, une étiquette et une cellule de grille exposent donc la même famille de propriétés d’image.

Dans IconDesk, le bouton Open reçoit un objet image que le serveur lit depuis un fichier. Le bouton Save reçoit un nom d’image de thème sur ImageSource. Print et Delete partagent une ImageList et choisissent leur image par clé : c’est la liste qui décide de ce qu’ils dessinent.

Une ImageList est une indirection plutôt qu’un stockage. Une clé porte un sens qui survit à un changement d’ordre, alors qu’un index n’est qu’une position et désigne silencieusement une autre image dès que la collection bouge. Remplacez l’image rangée sous une clé et tous les contrôles qui l’utilisent suivent, sans toucher au reste du code.

L’étiquette de diagnostic demande à chaque bouton, via IImage, quelle propriété d’image est réellement renseignée. Cette question attrape un défaut courant : une source d’image affectée après une clé prend l’emplacement, la clé reste définie, et le contrôle dessine la chaîne à la place. Lire le contrôle vaut mieux que deviner.

À l’exécution, quatre icônes arrivent par quatre chemins différents et paraissent toutes aussi correctes. Seul le bouton Open a fait décoder une image au serveur ; les trois autres ont été résolues par le navigateur. L’étiquette nomme le mécanisme derrière chacune : la différence se voit au lieu d’être supposée.

Remplacer l’image derrière la clé delete met à jour ce bouton tout seul, parce que le contrôle désigne la clé et non l’image. Affecter ensuite une source d’image au même bouton change ce qu’il dessine, tandis que la clé reste définie et ignorée.

Lab un : construisez le panneau de commandes d’IconDesk avec les trois mécanismes, ajoutez l’étiquette de diagnostic qui lit chaque bouton via IImage, et consignez ce qu’ont produit l’échange de clé et la double affectation.

Module 2. La page ImageLab d’IconDesk place côte à côte un objet image et une chaîne image-source sur des contrôles PictureBox, pour que la différence entre les deux pipelines devienne visible.

Demander quels formats Wisej.NET prend en charge n’a pas de réponse unique, et traiter la question ainsi provoque de vrais défauts. Un logo étiré hors proportion, une page figée pendant le téléchargement d’une photo distante, un fichier d’icône qui refuse de se charger : tout cela vient d’avoir fondu deux listes de formats en une seule.

Gardez les listes séparées. Bitmap, métafichier, icône, JPEG, GIF et PNG passent par System.Drawing et la propriété Image. Le gestionnaire de ressources et les images de thème acceptent JPEG, PNG, GIF, SVG et bitmap sous forme de chaînes. Le SVG appartient au pipeline des chaînes ; ce n’est pas un format System.Drawing.

Six modes de taille décrivent ce qui se passe quand l’image et la boîte ne sont pas d’accord. Normal rogne, AutoSize redimensionne la boîte à l’image, CenterImage centre, StretchImage déforme, Zoom fait tenir l’image entière, et Cover remplit la boîte en recadrant le débordement.

Quatre contrôles partagent une seule chaîne source et ne diffèrent que par le mode de taille, ce qui isole le dimensionnement du chargement. L’ancien fichier d’icône quitte la chaîne image-source pour la propriété Image, parce qu’icône et métafichier appartiennent au pipeline System.Drawing.

LoadAsync va chercher la photo partenaire sans bloquer la page pendant son arrivée. Une icône vectorielle, adressée comme une chaîne de ressource, alimente quatre tailles différentes à partir de la même ressource. Un gestionnaire de rapport indique ensuite, pour chaque PictureBox, si l’image vient de Image ou d’ImageSource.

À l’exécution, la même ressource est rognée par Normal, ajustée par Zoom, recadrée par Cover et aplatie par StretchImage. La photo distante est encore en route, et la page reste utilisable pendant son téléchargement : c’est tout l’intérêt du chargement asynchrone.

La rangée vectorielle reste nette à seize, vingt-quatre, trente-deux et quarante-huit pixels. Le petit bitmap est déjà flou à trente-deux, parce que le navigateur agrandit des pixels qui n’ont jamais existé. Le rapport nomme ensuite le pipeline derrière chaque contrôle, pour que personne n’ait à deviner.

Lab deux : construisez ImageLab avec quatre modes de taille sur une ressource matricielle, une photo distante via LoadAsync, une icône vectorielle à quatre tailles, le gestionnaire de rapport et la note de format.

Icônes et images, module 3. L’image d’un contrôle n’est souvent pas un fichier livré à côté de la page, mais une chaîne source, et l’écran IconGallery remplit cinq emplacements de cinq façons différentes.

Le module deux a laissé IconDesk avec un chemin tapé pour chaque apparence, ce qui convient jusqu’au jour où l’apparence doit changer. Un thème peut fournir l’image comme URL relative, URL absolue ou données intégrées, ou comme image nommée, et seule l’image nommée ajoute une indirection.

Affecter un nom d’image de thème à ImageSource n’ouvre aucun fichier et ne crée aucun System.Drawing.Image. Le nom est une clé que le client résout depuis le thème déjà chargé, et c’est pourquoi un autre thème peut fournir une autre image sans la moindre modification de votre code C#.

L’Image Selector du designer parcourt les images du projet, les images de thème et chaque pack d’icônes référencé, avec un aperçu de chacune. Pour les icônes monochromes, il prévisualise aussi la couleur : la décision de recoloration se prend en regardant, plutôt qu’en recompilant et en rafraîchissant.

Lisez ce que le sélecteur a écrit. Designer.cs contient une chaîne de source de ressource qui pointe vers l’assembly détenant l’image, jamais une copie du fichier lui-même. La même chaîne peut être calculée à l’exécution, ce qui compte quand l’icône dépend de l’état plutôt que de la mise en page.

Ajouter le suffixe de couleur à une chaîne source recolore une icône vectorielle monochrome adaptée. Une couleur littérale fonctionne, mais un nom de couleur de thème vaut mieux : l’icône suit alors le thème au lieu de figer une valeur qu’un futur changement de palette contredira silencieusement.

À l’exécution d’IconGallery, cinq emplacements sont remplis par une clé de thème, une URL relative, une URL absolue, une ressource de pack et une icône vectorielle recolorée. Toutes paraissent aussi solides, pourtant seule l’URL absolue dépend d’un hôte que vous ne contrôlez pas, et cela mérite d’être su avant le déploiement.

Changez maintenant de thème. La clé de thème se résout vers une nouvelle image, et la couleur de thème du suffixe change avec elle. Les trois sources qui désignaient une image précise restent identiques : c’est la différence entre une référence sémantique et une référence littérale.

Lab trois : remplissez IconGallery via l’Image Selector, recolorez une icône monochrome avec un nom de couleur de thème, lisez les chaînes dans Designer.cs, et rédigez la note de changement de thème.

Module 4. IconDesk a besoin de cinq icônes aujourd’hui et peut-être de quarante de plus ce trimestre. Les collecter fichier par fichier vous donne plusieurs épaisseurs de trait, aucun style commun et aucune trace de leur provenance.

Un pack d’icônes est un assembly .NET ordinaire dont les images sont stockées en ressources embarquées. Un seul fichier dans le dossier de sortie peut porter des centaines ou des milliers d’icônes, et chacune reste adressable individuellement via le gestionnaire de ressources : rien n’est empaqueté en un bloc inutilisable.

Les deux mécanismes livrent différemment, et cela décide de la place de chacun. Les icônes de pack sont tirées : une requête à la première utilisation, puis le cache du navigateur. Les images de thème sont poussées, préchargées avec le thème, et c’est pourquoi les très grands catalogues ont leur place dans un pack.

Installez les packs depuis les paquets officiels Wisej-4 et gardez leurs versions majeures alignées sur celle du framework. Compilez ensuite le projet avant de les chercher, car l’explorateur d’images ne liste que les packs contre lesquels le projet a réellement compilé.

Choisissez une icône et lisez ce que le designer a généré : le gestionnaire de ressources, l’assembly du pack, le fichier d’icône, et éventuellement le suffixe de couleur. Chaque partie de cette chaîne est vérifiée à l’exécution, et c’est pourquoi un nom de fichier tapé de mémoire ne résout rien.

En C#, préférez le catalogue d’icônes du pack à une chaîne écrite à la main : un renommage devient alors une erreur de compilation plutôt qu’un contrôle vide. L’espace de noms exact varie d’un pack à l’autre. Affectez une seule propriété d’image par contrôle, et gardez un libellé à côté de toute icône qui porte du sens.

La page IconCompare montre les cinq mêmes concepts dessinés par deux familles, ce qui rend la différence stylistique évidente comme aucune page de catalogue ne le fait. Deux icônes monochromes acceptent le suffixe de couleur avec un nom de couleur de thème ; une image multicolore l’ignore tout simplement.

Le panneau réseau fournit la preuve : une requête par icône au premier chargement, et des réponses depuis le cache au rechargement. Une recommandation appuyée là-dessus est défendable, et cela montre aussi pourquoi référencer un gros pack ne coûte pas un gros téléchargement à l’apprenant.

Lab quatre : référencez deux packs Wisej-4, construisez une page IconCompare à partir des deux, choisissez au moins cinq icônes dans l’explorateur, recolorez-en deux, et nommez la famille d’icônes principale du projet.

Icônes et images, module 5. Cinq ressources d’IconDesk cessent d’être des fichiers libres à côté de l’application et sont désormais livrées dans l’assembly, adressées par une chaîne plutôt que par un chemin sur le disque.

Une image déployée à côté de l’application est à une copie oubliée de la panne. Le serveur répond introuvable, le contrôle ne dessine rien, et le fichier est toujours présent sur la machine du développeur : c’est pourquoi le problème survit en général jusqu’à ce que quelqu’un d’autre lance la compilation.

Il n’y a pas d’API pour cela. Ajoutez le fichier au projet, mettez son action de génération sur Embedded Resource, et les octets passent dans le manifeste de l’assembly. Cette seule propriété transforme aussi une bibliothèque de classes ordinaire en pack d’icônes, comme le montrera le module six.

Adressez la ressource par une chaîne. Sans nom d’assembly, Wisej.NET cherche une ressource correspondante parmi les assemblies chargés. Nommer l’assembly explicitement, écrit sans l’extension de fichier, lève l’ambiguïté quand deux assemblies pourraient contenir chacun un fichier du même nom.

Le gestionnaire sert exactement neuf extensions : feuilles de style, scripts, HTML, JPEG dans ses deux orthographes, PNG, GIF, graphiques vectoriels et bitmaps. Rien d’autre n’est servi : un fichier d’icône embarqué avec de grands espoirs reste donc un introuvable, et la solution est de le convertir plutôt que de déboguer l’URL.

Un fichier déployé avec l’application peut répondre à la même adresse avant la copie embarquée. C’est utile pour la refonte visuelle d’un client ou un correctif urgent sans recompilation, et cela veut dire que le dossier de ces remplacements est désormais à protéger.

Dans le navigateur, cinq requêtes renvoient cinq réponses réussies, toutes servies depuis l’assembly de l’application, et le rechargement vient du cache à la place. L’image vectorielle reste du balisage d’un bout à l’autre ; à aucun moment elle ne devient une image System.Drawing.

Déposer un logo de remplacement à côté de l’application déployée change l’image sans aucune recompilation. Ensuite, une lettre doublée dans un nom de ressource produit un introuvable, et la checklist en six étapes le trouve à l’étape quatre, ce qui va plus vite que de relire le code.

Lab cinq : embarquez cinq ressources, affichez-les toutes sur ResourceLab, qualifiez une source avec le nom de l’assembly, remplacez-en une par un fichier déployé, et rédigez la chasse à l’introuvable.

Module 6. IconDesk utilise maintenant des icônes partout et n’en possède aucune. Le remède est un pack à lui : une bibliothèque de classes, un répertoire Resources, et douze icônes vectorielles marquées comme ressources embarquées.

Pour l’instant, la même icône s’écrit de quatre façons légèrement différentes sur quatre écrans. Chacun de ces chemins est une chaîne : trois d’entre eux compilent parfaitement et n’échouent que dans le navigateur, ce qui déplace l’erreur de la compilation vers l’écran d’un client.

La recette documentée tient en quatre étapes : créez une bibliothèque de classes, créez un répertoire Resources, mettez-y les icônes, et passez leur action de génération à Embedded Resource. Il en sort une adresse faite du gestionnaire, du nom de l’assembly et du chemin de la ressource. Vérifiez-la une fois contre l’application en cours d’exécution.

Le catalogue transforme cette adresse en IntelliSense. Une constante privée détient la partie commune du chemin, et une constante publique par icône nomme le concept plutôt que le fichier, de sorte que les appelants écrivent un nom produit comme Save ou Warning au lieu de répéter un chemin.

Deux routes aboutissent à la même chaîne. L’Image Selector l’écrit dans Designer.cs quand une décision de mise en page choisit l’icône, et le code d’exécution la lit dans le catalogue quand c’est l’état de l’application qui décide. Et l’image vectorielle reste du balisage que le client résout, jamais une image System.Drawing.

Ça tourne. Douze icônes viennent d’un seul assembly référencé, arrivant une requête à la fois à la première utilisation, puis servies depuis le cache au chargement suivant. Rien dans l’application n’avait besoin de savoir où vivent ces images sur le disque.

Le suffixe de couleur recolore deux icônes et est ignoré par la troisième, parce que ce fichier porte une couleur codée en dur dans l’image. Retirez cette valeur du balisage, puis revérifiez le résultat dans un thème sombre plutôt que de supposer que le correctif a suivi.

Trois habitudes maintiennent le pack en vie : un concept par icône, le catalogue traité comme l’API publique du pack pour qu’un renommage reste une affaire de compilateur, et un chemin de remplacement documenté pour une application qui a besoin d’une autre image sous le même nom familier.

Lab six : construisez IconDesk.Icons avec douze icônes embarquées et le catalogue, affectez-en dans le designer et depuis le code, vérifiez trois recolorations, et rédigez les règles de versionnage.

Icônes et images dans Wisej.NET, module 7, le projet final. IconDesk sait déjà dessiner une icône de cinq façons différentes. Il en gagne maintenant une sixième, et surtout la règle écrite qui tranche entre elles.

Un objet image, une chaîne image-source, une image de thème, une ressource embarquée, et maintenant une police d’icônes. Six mécanismes sans premier choix écrit : voilà comment la même commande Delete ne se ressemble plus sur trois écrans de la même application.

Une police d’icônes court-circuite entièrement le pipeline d’images. Un seul lien de feuille de style dans le Default.html suffit : le navigateur récupère le CSS et les fichiers de police, et une classe CSS dans le texte d’un contrôle qui autorise le HTML dessine le glyphe comme un caractère.

Aucune approche ne l’emporte. Les ressources Wisej apportent la recoloration, le sélecteur d’images et de vraies propriétés d’image. Les polices apportent un système de design CSS existant et un glyphe qui se place en ligne avec le texte. Réseau public ou serveur maison, c’est une vraie décision.

Dans le code, les deux décisions sont à des niveaux différents. Le lien de feuille de style vaut pour toute la page ; autoriser le HTML est une décision par contrôle, prise délibérément. Deux glyphes de rôles différents partagent alors une cellule de grille, et le clic indique l’élément touché.

Voici la politique. Les images de thème pour les visuels sémantiques qui suivent le thème. Un pack principal pour les commandes. Le pack personnalisé pour vos images produit. Le matriciel pour les photographies. Les polices d’icônes seulement là où l’intégration HTML paie la dépendance supplémentaire.

La page de synthèse fait tourner les cinq mécanismes d’un coup. Changez de thème : seules l’image de thème et l’icône vectorielle recolorée le suivent. L’icône de pack, celle du pack personnalisé et la ressource embarquée restent telles que dessinées, et la politique est écrite autour de ce comportement.

La colonne d’actions répond à deux clics différents depuis une seule cellule en lisant le rôle de l’élément touché. La passe qualité se répète ensuite en thème sombre, en vérifiant que chaque glyphe reste lisible et que chaque action porte encore un nom qu’un lecteur d’écran peut annoncer.

Le projet final : la feuille de style et une barre d’outils qui autorise le HTML, la colonne de grille sensible au rôle, la page de synthèse à cinq mécanismes, la politique d’icônes écrite, et la note qualité en thème clair et sombre.