Icons und Bilder in Wisej.NET

Icons und Bilder in Wisej.NET, Modul eins. Wisej.NET bietet mehrere Wege, ein Bild auf ein Control zu bringen. Die erste Entscheidung in diesem Kurs lautet deshalb immer: Welcher Mechanismus besitzt das Bild?

Die Eigenschaft Image hält ein System.Drawing.Image. Der Server behält es im Speicher und sendet es als PNG an den Browser. ImageSource hält nur eine Zeichenfolge, auf dem Server wird also nichts dekodiert. Beide füllen denselben visuellen Slot am Control. Genau deshalb muss die Wahl bewusst fallen.

Diese Zeichenfolge kann eine relative URL sein, eine absolute URL, ein benanntes Theme-Bild oder ein resource.wx-Pfad. Aufgelöst wird sie vom Client. Bildfähige Controls teilen sich einen Vertrag über IImage. Ein Button, ein Label und eine Grid-Zelle bieten deshalb dieselbe Familie von Bild-Eigenschaften.

In IconDesk bekommt der Open-Button ein Bildobjekt, das der Server aus einer Datei liest. Der Save-Button bekommt einen Theme-Bildnamen auf ImageSource. Print und Delete teilen sich eine ImageList und wählen ihre Grafik über einen Key. Die Liste entscheidet also, was diese beiden Buttons zeichnen.

Eine ImageList ist Indirektion, nicht Speicher. Ein Key trägt Bedeutung und übersteht ein Umsortieren. Ein Index ist nur eine Position und zeigt nach einer Änderung still auf eine andere Grafik. Tauschen Sie das Bild hinter einem Key aus, folgt jedes Control, das diesen Key verwendet, ganz ohne weiteren Code.

Das Diagnose-Label fragt jeden Button über IImage, welche Bild-Eigenschaft wirklich gefüllt ist. Diese Frage findet einen typischen Fehler: Wird eine Bildquelle nach einem Image-Key zugewiesen, übernimmt sie den Slot. Der Key bleibt gesetzt, und das Control zeichnet die Zeichenfolge. Das Control auszulesen schlägt jedes Raten.

Beim Ausführen der Seite kommen vier Icons auf vier verschiedenen Wegen an, und alle sehen gleich richtig aus. Nur beim Open-Button hat der Server ein Bild dekodiert. Die anderen drei hat der Browser aufgelöst. Das Label benennt den Mechanismus hinter jedem Icon, der Unterschied ist also sichtbar statt vermutet.

Tauschen Sie die Grafik hinter dem Delete-Key aus, ändert sich nur dieser Button, denn das Control verweist auf den Key und nicht auf das Bild. Weisen Sie demselben Button danach eine Bildquelle zu, ändert sich das Gezeichnete, während der Key gesetzt bleibt und ignoriert wird.

Lab eins: Bauen Sie die IconDesk-Befehlsleiste mit allen drei Mechanismen, ergänzen Sie das Diagnose-Label, das jeden Button über IImage ausliest, und halten Sie fest, was der Key-Tausch und die doppelte Zuweisung tatsächlich bewirkt haben.

Modul zwei. Die ImageLab-Seite in IconDesk stellt ein Bildobjekt und eine Bildquellen-Zeichenfolge auf PictureBox-Controls nebeneinander. So wird der Unterschied zwischen den beiden Pipelines zu etwas, das Sie sehen können.

Die Frage, welche Formate Wisej.NET unterstützt, hat keine einzige Antwort, und wer sie so behandelt, baut echte Fehler ein. Ein verzerrtes Logo, eine Seite, die auf ein entferntes Foto wartet, und eine Icon-Datei, die nicht lädt: Alle drei entstehen, wenn man zwei Formatlisten zu einer zusammenzieht.

Halten Sie die Listen getrennt. Bitmap, Metafile, Icon, JPEG, GIF und PNG laufen über System.Drawing und die Eigenschaft Image. Der Ressourcen-Handler und Theme-Bilder nehmen JPEG, PNG, GIF, SVG und Bitmap als Zeichenfolge. SVG gehört zur Zeichenfolgen-Pipeline und ist kein System.Drawing-Format.

Sechs Größenmodi beschreiben, was passiert, wenn Bild und Box nicht zusammenpassen. Normal beschneidet, AutoSize passt die Box an das Bild an, CenterImage zentriert, StretchImage verzerrt, Zoom passt das ganze Bild hinein, und Cover füllt die Box und schneidet den Überstand ab.

Vier Controls teilen sich eine Quell-Zeichenfolge und unterscheiden sich nur im Größenmodus. Das trennt die Größenentscheidung von der Ladeentscheidung. Die alte Icon-Datei wandert von der Bildquellen-Zeichenfolge auf die Eigenschaft Image, denn Icon und Metafile gehören zur System.Drawing-Pipeline.

LoadAsync holt das Partnerfoto, ohne die Seite anzuhalten, bis es da ist. Ein Vektor-Icon, über eine Ressourcen-Zeichenfolge adressiert, bedient vier Größen aus demselben Asset. Ein Report-Handler gibt danach für jede PictureBox aus, ob das Bild von Image oder von ImageSource kam.

Im Betrieb wird dasselbe Asset von Normal beschnitten, von Zoom eingepasst, von Cover zugeschnitten und von StretchImage plattgedrückt. Das entfernte Foto ist noch unterwegs, und die Seite bleibt bedienbar, während es lädt. Genau darum geht es beim asynchronen Laden.

Die Vektorreihe bleibt bei sechzehn, vierundzwanzig, zweiunddreißig und achtundvierzig Pixeln scharf. Die kleine Bitmap ist schon bei zweiunddreißig weich, denn der Browser vergrößert Pixel, die es nie gab. Der Report benennt dann die Pipeline hinter jedem Control, damit niemand raten muss.

Lab zwei: Bauen Sie ImageLab mit vier Größenmodi an einem Raster-Asset, einem entfernten Foto über LoadAsync, einem Vektor-Icon in vier Größen, dem Report-Handler und der Formatnotiz.

Icons und Bilder, Modul drei. Das Bild auf einem Control ist oft keine Datei neben der Seite, sondern eine Quell-Zeichenfolge. Der IconGallery-Bildschirm füllt fünf Slots auf fünf verschiedene Arten.

Modul zwei hat IconDesk mit einem getippten Pfad für jedes Aussehen zurückgelassen. Das trägt, bis sich das Aussehen ändern muss. Ein Theme kann das Bild als relative URL, als absolute URL, als eingebettete Daten oder als benanntes Bild liefern. Nur das benannte Bild fügt eine Schicht Indirektion hinzu.

Weisen Sie ImageSource einen Theme-Bildnamen zu, wird keine Datei geöffnet und kein System.Drawing.Image erzeugt. Der Name ist ein Key, den der Client aus dem bereits geladenen Theme auflöst. Deshalb kann ein anderes Theme eine andere Grafik liefern, ohne dass sich Ihr C#-Code ändert.

Der Image Selector im Designer durchsucht Projektbilder, Theme-Bilder und jedes Icon-Pack, das das Projekt referenziert, jeweils mit Vorschau. Für einfarbige Icons zeigt er auch die Farbe vorab. Eine Umfärbung entscheiden Sie also durch Hinsehen statt durch Neubauen und Neuladen.

Lesen Sie, was der Picker geschrieben hat. Designer.cs hält eine Ressourcen-Zeichenfolge, die auf die Assembly mit der Grafik zurückverweist, nie eine Kopie der Datei selbst. Dieselbe Zeichenfolge lässt sich zur Laufzeit berechnen. Das zählt, wenn das Icon vom Zustand abhängt und nicht vom Layout.

Ein Farbsuffix an der Quell-Zeichenfolge färbt ein geeignetes einfarbiges Vektor-Icon um. Ein wörtlicher Farbwert funktioniert, ein Theme-Farbname ist besser. Das Icon folgt dann dem Theme, statt einen Wert festzunageln, dem eine spätere Palette still widerspricht.

Im Betrieb füllt IconGallery fünf Slots über einen Theme-Key, eine relative URL, eine absolute URL, eine Pack-Ressource und ein umgefärbtes Vektor-Icon. Sie wirken gleich gesetzt, doch nur die absolute URL hängt an einem Host, den Sie nicht kontrollieren. Das sollten Sie vor dem Deployment wissen.

Jetzt wechseln Sie das Theme. Der Theme-Key löst sich auf neue Grafik auf, und die im Suffix genannte Theme-Farbe wandert mit. Die drei Quellen, die exakte Grafik benannt haben, bleiben identisch. Das ist der praktische Unterschied zwischen einer semantischen und einer wörtlichen Referenz.

Lab drei: Füllen Sie IconGallery über den Image Selector, färben Sie ein einfarbiges Icon mit einem Theme-Farbnamen um, lesen Sie die Zeichenfolgen in Designer.cs und schreiben Sie die Notiz zum Theme-Wechsel.

Modul vier. IconDesk braucht heute fünf Icons und in diesem Quartal vielleicht vierzig weitere. Sammelt man sie Datei für Datei, bekommt man mehrere Strichstärken, keinen gemeinsamen Stil und keinen Nachweis, woher etwas stammt.

Ein Icon-Pack ist eine gewöhnliche .NET-Assembly, deren Grafik als eingebettete Ressourcen liegt. Eine Datei im Ausgabeordner kann Hunderte oder Tausende Icons tragen, und jedes bleibt über den Ressourcen-Handler einzeln adressierbar. Nichts wird zu einem einzigen unbrauchbaren Block gebündelt.

Die beiden Mechanismen liefern unterschiedlich aus, und das entscheidet, wohin jeder gehört. Pack-Icons werden abgeholt: eine Anfrage bei der ersten Verwendung, danach der Browser-Cache. Theme-Bilder werden mitgeschickt und gemeinsam mit dem Theme vorgeladen. Deshalb gehören sehr große Kataloge in ein Pack.

Installieren Sie die Packs aus den offiziellen Wisej-4-Paketen und halten Sie deren Hauptversionen im Einklang mit dem Framework. Bauen Sie danach das Projekt, bevor Sie suchen: Der Image Explorer listet nur die Packs, gegen die das Projekt tatsächlich kompiliert wurde.

Wählen Sie ein Icon und lesen Sie, was der Designer erzeugt hat: den Ressourcen-Handler, die Pack-Assembly, die Icon-Datei und optional das Farbsuffix. Jeder Teil dieser Zeichenfolge wird zur Laufzeit geprüft. Deshalb löst sich ein aus dem Gedächtnis getippter Dateiname auf gar nichts auf.

Nutzen Sie in C# den Icon-Katalog des Packs statt einer getippten Zeichenfolge. Eine Umbenennung wird so zum Compilerfehler statt zu einem leeren Control. Der genaue Namespace hängt vom Pack ab. Setzen Sie eine Bild-Eigenschaft pro Control, und geben Sie jedem bedeutungstragenden Icon eine Beschriftung.

Die IconCompare-Seite zeigt dieselben fünf Konzepte, gezeichnet von zwei Familien. Der stilistische Unterschied wird so deutlich, wie es eine Katalogseite nie schafft. Zwei einfarbige Icons nehmen das Farbsuffix mit einem Theme-Farbnamen an, mehrfarbige Grafik ignoriert es einfach.

Das Netzwerkpanel liefert den Beleg: eine Anfrage pro Icon beim ersten Laden, Cache-Treffer beim Neuladen. Eine so gestützte Empfehlung ist belastbar. Sie zeigt außerdem, warum der Verweis auf ein großes Pack den Lernenden keinen großen Download kostet.

Lab vier: Referenzieren Sie zwei Wisej-4-Packs, bauen Sie daraus eine IconCompare-Seite, wählen Sie mindestens fünf Icons im Explorer, färben Sie zwei um und benennen Sie die primäre Icon-Familie des Projekts.

Icons und Bilder in Wisej.NET, Modul fünf. Fünf IconDesk-Assets sind keine losen Dateien neben der Anwendung mehr. Sie reisen in der Assembly mit, adressiert über eine Zeichenfolge statt über einen Pfad auf der Platte.

Grafik, die neben der Anwendung ausgeliefert wird, ist einen vergessenen Kopierschritt vom Ausfall entfernt. Der Server antwortet mit einem Nicht-gefunden, das Control zeichnet nichts, und auf dem Entwicklerrechner liegt die Datei weiterhin. Deshalb überlebt das Problem meist, bis jemand anderes den Build ausführt.

Dafür gibt es keine API. Fügen Sie die Datei dem Projekt hinzu und setzen Sie ihre Build Action auf Embedded Resource. Die Bytes wandern in das Manifest der Assembly. Genau diese eine Eigenschaft macht aus einer gewöhnlichen Klassenbibliothek auch ein Icon-Pack, wie Modul sechs zeigen wird.

Adressieren Sie die Ressource als Zeichenfolge. Ohne Assembly-Namen durchsucht Wisej.NET die geladenen Assemblys nach einer passenden Ressource. Den Assembly-Namen ausdrücklich zu nennen, geschrieben ohne Dateiendung, beseitigt die Mehrdeutigkeit, wenn zwei Assemblys je eine Datei gleichen Namens enthalten könnten.

Der Handler liefert genau neun Erweiterungen aus: Stylesheets, Skripte, HTML, JPEG in beiden Schreibweisen, PNG, GIF, Vektorgrafik und Bitmaps. Sonst nichts. Eine hoffnungsvoll eingebettete Icon-Datei bleibt also ein Nicht-gefunden, und die Lösung heißt konvertieren statt die URL zu debuggen.

Eine mit der Anwendung ausgelieferte Datei kann dieselbe Adresse vor der eingebetteten Kopie beantworten. Das ist bei einem Kunden-Rebranding oder einer dringenden Korrektur ohne Neubau wirklich nützlich. Es heißt aber auch: Der Ordner mit diesen Überschreibungen ist jetzt etwas, das Sie schützen müssen.

Im Browser beantworten fünf Anfragen fünf erfolgreiche Antworten, alle aus der Anwendungs-Assembly, und das Neuladen kommt stattdessen aus dem Cache. Die Vektorgrafik bleibt durchgehend Markup. Sie wird an keiner Stelle zu einem System.Drawing-Bild.

Legen Sie ein Ersatzlogo neben die ausgelieferte Anwendung, und das Bild ändert sich ganz ohne Neubau. Danach erzeugt ein doppelter Buchstabe in einem Ressourcennamen ein Nicht-gefunden, und die Sechs-Schritte-Checkliste findet ihn in Schritt vier. Das ist schneller, als den Code erneut zu lesen.

Lab fünf: Betten Sie fünf Assets ein, zeigen Sie alle auf ResourceLab, qualifizieren Sie eine Quelle mit dem Assembly-Namen, überschreiben Sie eine per Datei und dokumentieren Sie die Fehlersuche.

Modul sechs. IconDesk verwendet inzwischen überall Icons und besitzt keines davon. Die Abhilfe ist ein eigenes Pack: eine Klassenbibliothek, ein Resources-Ordner und zwölf Vektor-Icons, die als eingebettete Ressourcen markiert sind.

Im Moment wird dasselbe Icon auf vier Bildschirmen auf vier leicht verschiedene Arten geschrieben. Jeder dieser Pfade ist eine Zeichenfolge, drei davon kompilieren also einwandfrei und scheitern erst im Browser. Damit wandert der Fehler vom Build auf den Bildschirm eines Kunden.

Das dokumentierte Rezept hat vier Schritte: eine Klassenbibliothek anlegen, einen Resources-Ordner anlegen, die Icons hineinlegen und ihre Build Action auf Embedded Resource setzen. Heraus kommt eine Adresse aus Handler, Assembly-Name und Ressourcenpfad. Prüfen Sie sie einmal gegen die laufende Anwendung.

Der Katalog macht aus dieser Adresse IntelliSense. Eine private Konstante hält den gemeinsamen Teil des Pfades, und je eine öffentliche Konstante pro Icon benennt das Konzept statt der Datei. Aufrufer schreiben also einen Produktnamen wie Save oder Warning, statt einen Pfad zu wiederholen.

Zwei Wege enden bei derselben Zeichenfolge. Der Image Selector schreibt sie in Designer.cs, wenn eine Layout-Entscheidung das Icon wählt, und Laufzeitcode liest sie aus dem Katalog, wenn der Anwendungszustand entscheidet. Die Vektorgrafik bleibt dabei Markup, das der Client auflöst, nie ein System.Drawing-Bild.

Es läuft. Zwölf Icons kommen aus einer referenzierten Assembly, einzeln angefordert, sobald sie erstmals gebraucht werden, und beim nächsten Laden aus dem Browser-Cache bedient. Nichts in der Anwendung musste wissen, wo auf der Platte die Grafik liegt.

Das Farbsuffix färbt zwei Icons um und wird vom dritten ignoriert, weil in dieser Datei eine Farbe fest in der Grafik steht. Entfernen Sie den fest kodierten Wert aus dem Markup und prüfen Sie das Ergebnis danach im dunklen Theme, statt die Korrektur zu unterstellen.

Drei Gewohnheiten halten das Pack wartbar: ein Konzept pro Icon, der Katalog als öffentliche API des Packs, damit Umbenennen Sache des Compilers bleibt, und ein dokumentierter Überschreibungsweg für eine Anwendung, die unter demselben vertrauten Namen andere Grafik braucht.

Lab sechs: Bauen Sie die Bibliothek IconDesk.Icons mit zwölf eingebetteten Icons und dem Katalog, weisen Sie einige im Designer und einige im Code zu, prüfen Sie drei Umfärbungen und schreiben Sie die Versionierungsregeln.

Icons und Bilder in Wisej.NET, Modul sieben, das Abschlussprojekt. IconDesk kann ein Icon bereits auf fünf Arten zeichnen. Jetzt kommt eine sechste dazu, und wichtiger noch: die schriftliche Regel, die zwischen ihnen entscheidet.

Ein Bildobjekt, eine Bildquellen-Zeichenfolge, ein Theme-Bild, eine eingebettete Ressource und jetzt eine Icon-Schrift. Sechs Mechanismen ohne schriftlich festgelegte erste Wahl: So sieht derselbe Delete-Befehl auf drei Bildschirmen derselben Anwendung unterschiedlich aus.

Eine Icon-Schrift umgeht die Bild-Pipeline vollständig. Ein Stylesheet-Link in der Default.html der Anwendung lässt den Browser das CSS und die Schriftdateien holen, und eine CSS-Klasse im Text eines Controls, das HTML erlaubt, zeichnet die Glyphe als Zeichen.

Keine Seite gewinnt klar. Wisej-Ressourcen bringen das Umfärben, den Image Selector und echte Bild-Eigenschaften. Schriften bringen ein vorhandenes CSS-Designsystem und lassen eine Glyphe inline im Text sitzen. Ob dieses Stylesheet aus einem öffentlichen Netz oder von Ihrem eigenen Server kommt, ist eine echte Entscheidung.

Im Code liegen die beiden Entscheidungen auf verschiedenen Ebenen. Der Stylesheet-Link gilt für die ganze Seite, HTML zu erlauben ist eine bewusste Entscheidung pro Control. Zwei Glyphen mit unterschiedlichen Rollen teilen sich dann eine Grid-Zelle, und der Klick meldet, welches Element tatsächlich getroffen wurde.

Und hier ist die Richtlinie. Theme-Bilder für semantische Grafik, die dem Theme folgt. Ein primäres Pack für Befehle. Das eigene Pack für Produktgrafik, die Ihnen gehört. Rasterformate für Fotos. Icon-Schriften nur dort, wo sich die HTML-Integration die zusätzliche Abhängigkeit wirklich verdient.

Die Übersichtsseite führt alle fünf Mechanismen gleichzeitig vor. Wechseln Sie das Theme, folgen nur das Theme-Bild und das umgefärbte Vektor-Icon. Das Pack-Icon, das Icon aus dem eigenen Pack und das eingebettete Asset bleiben genau so gezeichnet. Um dieses Verhalten herum ist die Richtlinie geschrieben.

Die Aktionsspalte beantwortet zwei verschiedene Klicks aus einer einzigen Zelle, indem sie die Rolle des getroffenen Elements ausliest. Der Qualitätsdurchgang wiederholt sich danach im dunklen Theme und prüft, ob jede Glyphe noch lesbar ist und jede Aktion einen Namen trägt, den ein Screenreader ansagen kann.

Das Abschlussprojekt: das Stylesheet und eine Toolbar, die HTML erlaubt, die rollenbewusste Grid-Spalte, die Übersichtsseite mit fünf Mechanismen, die schriftliche Icon-Richtlinie und eine Qualitätsnotiz zu Hell und Dunkel.