Ab sofort steht unter http://devtyr.norberteder.com mein neues Blog zur Verfügung. Dieses Blog wird nicht weiter betreut, bleibt aber erhalten. Neue Eintr%auml;ge erfolgen nur mehr im neuen Blog. Kommentare werden ebenfalls nicht mehr behandelt. Wer weiterhin meinen Einträgen und Aktivitäten folgen möchte, möge bitte RSS-Feeds, Verlinkungen etc. an die neue Location anpassen.
WPF: Windows System Fonts in einer CoomboBox darstellen
Viele kennen die ComboBox mit den Systemschriften aus den diversen Office-Produkten und auch anderen Anwendungen. Nicht nur, dass der Name der Schrift angezeigt wird, man bekommt auch gleich eine Vorschau.
Dass die Umsetzung nicht aufwändig ist, zeigt nachfolgendes Beispiel. Hierzu das notwendige XAML:
Hier wird eine ComboBox angelegt, das ItemsPanel überschrieben (aus Performancegründen) und ein DataTemplate für die Darstellung der einzelnen Items definiert.
Das DataTemplate besteht aus einem TextBlock, welchem via Data Binding der Text (Name der Schriftart) als auch die FontFamily (die zu verwendende Schriftart zur Darstellung) übergeben werden.
Im Source ist dann nur mehr folgende Zeile notwendig und das Ergebnis kann bewundert werden:
Die System-Schriften sind in Fonts.SystemFontFamilies aufgelistet und können direkt an die ItemsSource-Eigenschaft der ComboBox übergeben werden. Damit werden automatisch die einzelnen Items hinzugefügt und die Werte mittels dem oben definierten Data Binding zugewiesen.
Fertig ist die Fonts-ComboBox. Und so sieht sie aus:
25.03.08 - .NET, Grundlagen, WPF Beitrag von Norbert Eder
Ressourcen sind ja doch eine häufige Angelegenheit in WPF. Klar, immerhin möchten Styles definiert werden, oder manches Mal sollte vielleicht auch ein Array definiert werden, warum auch immer. Und genau hier scheint es ein Problem zu geben.
Ich muss gleich vorweg nehmen, dass ich mich jetzt nicht auf die Suche nach einem offiziellen Bug-Eintrag gemacht habe, sondern poste dies jetzt, da es mir gerade eben aufgefallen ist. Für sachdienliche Hinweise (eine weitere Evaluierung wird meinerseits erst morgen stattfinden) bin ich natürlich dankbar.
Nehmen wir folgendes XAML (eingebettet in ein Window):
Eigentlich ist alles korrekt. Das Hauptaugenmerk ist weniger auf den Style, als auf das definierte Array zu legen. Das Problem besteht darin, dass die Daten, welche durch das Array angeboten werden, in der ListBox schlichtweg nicht angezeigt werden.
Nun, das kuriose, wird das Array zu Beginn der Fenster-Ressourcen definiert, dann funktioniert es. Also so:
Diese Variante funktioniert tadellos. Der einzige Unterschied: Das Array wurde - wie bereits erwähnt - zu Beginn der Ressourcen definiert.
Selbst wenn dies ein gewolltes Verhalten ist, kann ich es nicht nachvollziehen. Zumal jedes beliebige Array angezeigt werden kann (egal an welcher Position), wenn die erste Definition innerhalb der Ressourcen ein Array ist. D.h. in diesem Fall kann zwischen unterschiedlichen Array-Definitionen auch ein oder mehrere Style-Elemente vorhanden sein, es funktioniert dann trotzdem.
Cosmos is an operating system project implemented completely in CIL compliant languages.
Mit Hilfe eines User-Kits kann dann gleich mal gestartet werden. Zusätzlich dann auch gleich noch die Möglichkeit, das ganze in Emulatoren laufen zu lassen:
Cosmos runs in QEMU, VMWare, and VirtualPC. QEMU is best for debugging as it has extra debugging support which we use to integrate with GDB.
Und wie funktioniert es?
Cosmos includes a compiler (IL2CPU, which is part of Cosmos) that reads the input file (usually the shell) and Cosmos libraries and compiles the resulting IL to x86 code. IL2CPU has a layer for cross platform and we plan to support other processors and platforms, including x64. IL2CPU also supports certain extension methods which allow C# code to interact directly with the CPU, registers, and ports in the kernel. IL2CPU contains some inline assembler, but there are no ASM files that need to be linked in.
Currently IL2CPU first outputs raw asm files (with IL comments) and then processes them through nasm (a free assembler). Later we plan to emit directly to binary.
25.03.08 - .NET, Grundlagen, WPF Beitrag von Norbert Eder
Bisher waren Events genau einem einzigen Element zugewiesen und wurden am angehängten Eventhandler behandelt. Mit WPF wurden die so genannten Routed Events eingeführt, welche sich je nach Strategie durch den WPF Elementbaum bewegen. Insgesamt gibt es drei unterschiedliche Arten dieser Weiterleitungen
Bubbling
Tunneling
Direkt
Bubbling
Zuerst wird der Eventhandler der Quelle aufgerufen. Wird also bein Button geklickt wird der direkt angehängte Eventhandler aufgerufen. Anschließend wird das Event an alle Elternelemente weitergereicht, bis das Wurzelelement erreicht ist.
Tunneling
Der Eventhandler des Wurzelelements wird als erstes aufgerufen. Dieser gibt das Event anschließend an alle Kinder weiter, bis der Auslöser erreicht wird.
Direkt
Die direkte Event-Strategie entspricht der Funktionsweise, wie wir sie bis dato gewohnt waren. D.h. nur das Element selbst erhält das Event.
Warum routed Events
Als Entwickler ist es nicht immer notwendig zu wissen, welche Strategie nun für das Event implementiert wurde, da spezielles Verhalten entsprechend versteckt wurde. Notwendig wird das Wissen um routed Events bei der Erstellung von eigenen Steuerlementen usw.
Listener und Quellen von routed Events müssen kein eigenes Event in ihrer Hierarchie teilen. Jedes UIElement bzw. ContentElement kann ein Listener sein. Vielmehr agieren die routed Events als "Interface" worüber Informationen ausgetauscht werden können.
Ebenfalls ist es möglich, über den Elementbaum hinweg zu kommunizieren, da die Event-Daten an jedes Element im Baum weitergereicht werden und somit für alle sichtbar sind. So kann beispielsweise ein Element die Daten verändern, worauf ein anderes Element entsprechend reagieren kann.
Weitere Informationen
Weitere Informationen können über das MSDN bezogen werden. Ein guter Einstiegspunkt findet sich im Artikel Routed Events Overview.
24.03.08 - .NET, Grundlagen, WPF Beitrag von Norbert Eder
Für einfache Anwendungen unter WPF ist es sicherlich nicht erforderlich, über den logischen und visuellen Baum Bescheid zu wissen. Sobald jedoch eigene Elemente erstellt werden, kommt man unweigerlich damit in Berührung. Daher ist es gut und sinnvoll, den Unterschied zu kennen.
Logischer Baum
Im logischen Baum unter WPF befinden sich alle Elemente, die via XAML bzw. Code erzeugt wurden. Dies ist notwendig, damit nicht nur der Entwickler, sondern WPF selbst über sämtliche Child-Objekte informiert ist und darüber iterieren kann. Ebenfalls wird darüber ein Nachrichtensystem (Notifications) abgebildet. Hilfsmethoden werden über die Klasse LogicalTreeHelper angeboten.
Visueller Baum
Der logische Baum kann nun Elemente enthalten, die nicht unbedingt sichtbar sein müssen. Der visuelle Baum hingegeben (wie der Name schon sagt) beinhaltet alle Elemente, die sichtbar sind und somit von Visual ableiten. Dieser Baum ist vor allem für Entwickler interessant, die ihre eigenen Controls entwickeln und daher genau wissen müssen, wie der visuelle Baum dahinter aussieht. Hilfsmethoden werden über die Klasse VisualTreeHelper angeboten.
Für weitere Informationen empfiehlt sich der Artikel Trees in WPF im MSDN.
Schon eine sehr geile Sache, hier im Video zu sehen. Ist ja doch schon so einiges möglich. Zu achten bitte auf die Tritt-Szene bzw. die Szene auf dem Eis. Wirklich gut. Aber der Sound ist grässlich und erinnert irgendwie an "Die Fliege". Ach ja, und auf den letzten Screen zu achten, das gibt Aufschluss darüber, wo das denn wohl eingesetzt werden wird. Hier aber das Video:
Mittlerweile bin ich ja gerade dabei, mein Büro in den eigenen vier Wänden einzurichten. Ein dafür recht wichtiges Teil habe ich ja bereits seit einigen Monaten daheim herumstehen. Den NSLU2 von Linksys. Ein kleines NAS-Gerät, an dem 2 USB-Platten angehängt werden können. Am Wochenende war es dann soweit. Es konnte einfach nicht mehr warten, da Daten zwischen mehreren Rechnern ausgetauscht werden mussten und die Backups sollten auch endlich wieder laufen.
Ergo dieses kleine Ding einfach an den Router angeschlossen, ein Western Digital My Book dran und den Treiber auf den jeweiligen Rechnern isntallieren, um das Teil gemappt zu bekommen.
Der Vorteil vom Western Digital My Book ist der, dass sich die Platte nach einer gewissen Zeit ausschaltet und erst beim nächsten Request wieder "hoch fährt". Das spart natürlich einiges an Energie und die zwei bis drei Sekunden mehr beim erstmaligen Verbinden fallen durchaus nicht ins Gewicht.
Auf jeden Fall insgesamt eine recht günstige Alternative für ein Netzlaufwerk für den Austausch von Daten zwischen mehreren Rechnern und als Datenstore.
17.03.08 - .NET, Grundlagen, Base Framework, WPF, Datenverwaltung Beitrag von Norbert Eder
Wie die Zeit vergeht. So habe ich doch glatt vergessen, meinen letzten Artikel in der visual studio one anzukündigen. Das Thema: Techniken miteinander verbinden.
Einzelne Technologien und Techniken sind oft schnell verinnerlicht und werden anfänglich für kleinere Projekte eingesetzt. Meist jedoch getrennt voneinander, um etwaige Fehlerquellen oder ›Blocker‹ zu minimieren. Dieser Artikel zeigt, wie LINQ mit der Windows Presentation Foundation zusammen spielt.
Der gesamte Artikel ist in der Ausgabe 02/08 der Zeitschrift visual studio one zu finden.
Eine Liste der von mir verfassten Artikel ist in der Rubrik Zeitschriften-Artikel zu finden.
16.03.08 - .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, SQL Server Beitrag von Norbert Eder
Unter dem nachfolgenden Link sind einige Livemitschnitte vom Lauchevent 2008 in Frankfurt zu finden. Zum Ansehen wird das Silverlight-Plugin benötigt.
- Keynote
- Neu in Visual Studio 2008
- SQL Server 2008
- Überblick Windows Server 2008 Management
- Internet Information Server 7
- Virtualisieren mit dem Windows Server
Aber mit Windows Forms bin ich doch viel schneller …
14.03.08 - Entwicklung, Diskussionen, Grundlagen, WPF Beitrag von Norbert Eder
Genau diese Aussage ist mir bei Diskussionen rund um die Windows Presentation Foundation immer wieder untergekommen. Gerade wenn es um kleine Anwendungen geht, wird immer noch hauptsächlich auf Windows Forms gesetzt. Hier kommen natürlich einige Punkte zu tragen, die ich schon an diversen Stellen aufgeführt habe:
Gewohnheit: Windows Forms kennt man und weiß sie auch einzusetzen. Probleme sind genauso bekannt wie die möglichen Umsetzungsvarianten. Der Umstieg zu einer deklarativen Form (obwohl das ja auch nur ein Teil der WPF ist) ist somit nicht einfach zu bewerkstelligen, zumal bei kleinen Anwendungen, Tools, Hilfen die Vorteile bei weitem nicht so klar auf der Hand liegen.
Es ist neu. Neues verursacht immer wieder Angst. Man weiß nicht, womit genau man’s zu tun hat, wie es reagiert, was man damit alles machen kann. Im ersten Schritt werden daher grundlegende Informationen besorgt, welche dann natürlich aber auch sehr schnell zeigen können, dass etwas eventuell aufwändiger ist, als man es bisher gewohnt war. In einigen Fällen (und hier zähle ich die WPF dazu) wirkt dies jedoch nur auf den ersten Blick so. Allerdings muss hier auch die Größe der Anwendung berücksichtigt werden.
Es ist anders. Ganz klar, es ist natürlich anders, weil es neu ist. Bei neuen Techniken werden oft neue (oder aufgewärmte) Wege gegangen. Im Falle der WPF handelt es sich dabei um den Einsatz einer deklarativen Programmierung, soweit es zumindest XAML betrifft. Dies mag auf den ersten Blick etwas aufwändig erscheinen, dennoch ermöglicht gerade dies ungeahnte Möglichkeiten in der Trennung zwischen Design und Logik.
Zusätzlich zu diesen Punkten wird oftmals der im Visual Studio integrierte WPF Designer (Cider) kritisiert. Es wird bemängelt, dass Oberflächen nun nicht mehr so einfach und schnell erstellt werden können, wie dies unter Windows Forms der Fall ist. Das ist grundsätzlich schon richtig. Für diese Fälle gibt es Tools á la Expression Blend (dazu kommen wir noch). Auch unterscheidet sich hier ein bestimmter Punkt ganz gewaltig: Gestaltungsfreiheit.
War ich unter den Windows Forms noch an die angebotenen Gestaltungsmöglichkeiten des entsprechenden Steuerelements gebunden, ist dies unter WPF großteils so nicht mehr der Fall. Durch die Möglichkeit, beliebige Steuerelemente ineinander zu verschachteln, kann ich als Designer/Entwickler gänzlich neue Steuerelemente erzeugen, ohne wirklich programmieren zu müssen. Unter den Windows Forms musste ich für eine eigene Konstellation eben mal schnell ableiten und meinen Wunsch implementieren. Aber auch dieses gilt wieder nur für größere Anwendungen, da hier dieser Fall wahrscheinlicher auftritt, als bei einem kleinen Tool, welches ich als Entwickler nur für mich selber zusammenstricke.
Ein häufiges Argument, welches ebenfalls oft angewandt wird: Expression Blend ist zwar toll, kostet aber auch entsprechend. Ein kurzer Blick auf eine Homepage die etwas mit kriegerischen Frauen zu tun hat, zeigt: Expression Blend schlägt mit über 500 Euronen zu Buche. Dies ist in der Tat ein Betrag, den sich ein Hobbyentwickler, oder jemand der OpenSource-Software entwickelt, kaum leisten kann, bzw. vielmehr will. Ist auch verständlich. Gehen wir hier also nicht von einem professionellen Rahmen aus (hier sollte dieser Betrag aufzutreiben sein), sondern wenden wir uns diesbezüglich den Hobbyentwicklern zu. Wo sind also die Alternativen. Ja, da gibt es den Aurora XAML Designer, der jedoch auch nicht kostenfrei ist (jedoch mit unter 200 Euro noch erträglich) und zudem auch nicht so wirklicht gut abschneidet (siehe Aurora XAML Designer Schnelltest).
Weitere Alternativen sind rar und oft finden sich nur kleinere Tools, die den einen oder anderen Schritt automatisieren oder vereinfachen. Hier muss also noch auf jeden Fall nachgebessert werden, denn der „kleine Entwickler“ muss sehr viel zu Fuß erledigen und verliert damit dann schon Zeit, die vielleicht besser in die Logik investiert wäre.
Es muss jedoch auch hinzugefügt werden, dass sich der Aufwand durchaus in Grenzen hält und man auch sehr schnell zu Ergebnissen kommt. Fakt ist jedoch, dass gewisse Schritte nicht gemacht werden wollen, wenn man ganz genau weiß, dass es grundsätzlich Tools gibt, die das viel schneller erledigen, oder es Alternativen gibt, die das auch für mich machen. Windows Forms eben. Und solange die Unterstützung auf diesem Gebiet nicht besser ist, wird sich WPF, vor allem in der großen Gemeinde, der „kleinen Entwickler“, nicht durchsetzen. Stattdessen werden weiterhin die Windows Forms zum Einsatz kommen. Da zählen die Vorteile die durch die WPF geboten werden, eigentlich nicht wirklich …