.NET Blog   ·   .NET Casts   ·   .NET GUI Foren   ·   .NET BlogBook   ·   WPF Blogger   ·   visual studio one   ·   ASP.NET professional

  • ACHTUNG - NEUES BLOG

    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.
Download .NET Essentials Installer
Trickkiste

.NET BlogBook geht in die 7. Runde

15.10.08 - Blog-Intern, .NET, Grundlagen, WPF, ASP.NET, Internet, Community
Beitrag von Norbert Eder
 Heute ist der Tag der Wahrheit. Es steht mittlerweile die siebte Ausgabe des .NET BlogBooks zur Verfügung.

Diese Ausgabe bringt eine Reihe an Neuerungen mit sich:
  • Es gibt aktuell kein gesamtes PDF mehr. Die einzelnen Teilbereiche wurden in einzelne Dateien verpackt. Damit bekommt jeder den Bereich, der in interessiert, Downloadgrößen und -zeiten werden dadurch minimiert.
  • Alles wurde in ein neues Layout verpackt. Damit wird sichergestellt, dass die Lesbarkeit nun besser gegeben ist und auch die Ergebnisse beim Druck positiver ausfallen.
  • Natürlich wurden auch neue Beiträge eingearbeitet.

Da dies einen relativ hohen Aufwand darstellt, steht zur aktuellen Zeit nur der Bereich Windows Presentation Foundation zur Verfügung. Die weiteren Teile werden im Laufe der kommenden Tage und der nächsten Woche nachgeliefert.

Auf jeden Fall würden wir uns über Rückmeldungen sehr freuen und hoffen, dass wir das erhaltene Feedback gut umsetzen konnten.

Weitere Informationen und Download-Möglichkeiten finden sich auf der Projekt-Homepage unter http://www.dotnet-blogbook.com

  3 Kommentare - 774 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Einstieg in NHibernate leicht gemacht

10.08.08 - .NET, Grundlagen, Datenverwaltung
Beitrag von Norbert Eder
 Hibernate ist mittlerweile kein unbekannter O/R Mapper mehr. Ursprünglich aus der Java-Welt, gibt es bereits seit langer langer Zeit auch eine Portierung für .NET, NHibernate genannt.

Auch bei mir laufen einige meiner Projekte erfolgreich auf NHibernate. Demzufolge bekomme ich immer wieder Anfragen diesbezüglich. Meist geht es darum, wie denn ein erstes Projekt (egal ob Demo-Anwendung oder Real-World-Applikation) gestartet werden kann.

Da NHibernate jetzt nicht unbedingt meinem Hauptfokus entspricht, hatte ich mich immer geweigert, einen kurzen Artikel diesbezüglich zu verfassen. Und wie es auch sein sollte, stieß ich - auf der Suche nach einer guten Einführung - auf folgenden Artikel, den ich NHibernate-Einsteiger nur wärmstens empfehlen kann:

Your first NHibernate based application

Darin wird sehr gut in einfachen Schritten erklärt, wie man eine erste Anwendung basierend auf NHibernate umsetzen kann. Die weiteren Schritte liegen dann wohl darin, sich einen eigenen entkoppelten Layer zu basteln, welcher für weitere Anwendungen eingesetzt werden kann.


  1 Kommentar - 1721 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Generische Liste mit dynamischem Typ

05.08.08 - .NET, Grundlagen, Base Framework
Beitrag von Norbert Eder
 Da ich gefragt wurde, wie man eine generische Liste mit einem dynamischen Typen erstellen kann, hier ein kurzer Codeteil, welcher genau dies zeigt:
Type t = Type.GetType("System.String");   
IList tempList = (IList)Activator.CreateInstance(
               (typeof(List<>).MakeGenericType(t))
            );  
Console.WriteLine(tempList.GetType().FullName);


  2 Kommentare - 942 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Events unter .NET

05.05.08 - .NET, Grundlagen, Base Framework
Beitrag von Norbert Eder
 Nachdem immer wieder die Frage auftaucht, wie denn Events unter .NET funktionieren, wie man eigene Events definieren kann usw. habe ich ein kleines Tutorial dafür geschrieben. Zu finden ist es hier.

Auf dass es dem einen oder anderen helfen möge.

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Na? Welche .NET Framework-Version darf es denn sein?

28.04.08 - .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei
Beitrag von Norbert Eder
 Wohl eine der häufigsten Fragen (gleich neben: "Wie bekomme ich Wert A von Form1 nach Form2?") ist wohl die, welche .NET Framework-Version eingesetzt werden soll/darf/muss.

Ein durchaus nicht (immer) einfach zu klärendes Thema. Grundsätzlich wäre es ja sehr einfach: Nimm die Version, die alles enthält, was du auch wirklich benötigst. Damit läßt sich die Frage jedoch nicht gänzlich beantworten.

Oft sind beim Kunden Prozesse am Laufen, die eine freie Wahl des .NET Frameworks nicht zuläßt (lange Evaluierungsphasen bezüglich der Sicherheit, Funktionsfähigkeit usw. fallen hier auf Anhieb ein). In diesen Fällen muss mit dem Kunden zusammen abgestimmt werden, was denn bei ihm tatsächlich verwendet werden darf. Dies betrifft nicht nur das Framework selbst, sondern auch unterschiedlichste Tools und Libraries aller Art. Bereits im Vorfeld muss eine Abgrenzung stattfinden. Dürfen 3rd Party Controls/Libraries verwendet werden? Wenn ja, welche? Diese und weitere Fragen tauchen auf.

Kunden, die derartige Einschränkungen nicht zu Tage liefern sollten jedoch auch nicht gleich mit der full featured Variante ausgestattet werden. Nach einer ordentlichen Evaluierung der Anforderungen sollte schnell klar sein, welche Komponenten notwendig sind. Dies inkludiert auch das Framework. Zukunftsdenken ist schön und oft auch unerläßlich, dennoch würde es beispielsweise wenig sinnvoll sein, eine Konsolenanwendung zum Datentransfer mit dem .NET Framework 3.5 zu implementieren. Version 2.0 ist vollkommen ausreichend. Im Falle einer Serveranwendung kommt dies eventuell nicht so schwer zu tragen (abgesehen davon, dass am Server wirklich nur das Notwendigste installiert werden sollte). Wird ein Produkt auf zig Hundert Rechner ausgeliefert, kann dies sehr wohl einen Unterschied machen. Version 2 sollte auf den meisten Rechnern installiert sein, 3.5 hingegen nicht. Dies würde einen zusätzlichen Deployment-Aufwand mit sich bringen, der nicht zur Zeit und somit auch Geld kostet, sondern eventuell auch auf der einen oder anderen Maschine zu Problemen führt (Murphy läßt grüßen).

Bei der Wahl der richtigen Framework-Version, als auch der verwendeten Tools und Libraries kann also ruhig auch ein wenig Pragmatismus ins Spiel kommen.

Ähnlich der obigen Überlegung sieht es bei der Entwicklung eines Frameworks aus. Oft erscheint in der Zwischenzeit eine neue Version des Frameworks. Eine Umstellung würde Aufwand bedeuten (mal davon abgesehen, dass eventuell neue Features hinzukommen und der begeisterte Feature-Junkie gleich ein Refactoring und ein Recoding in den Raum wirft). Hier muss überlegt werden, auf welcher Version die darauf aufbauenden Zielprojekte umgesetzt werden (sollen). Ist zu rechnen, dass eben diese Projekte auf die neue .NET Framework Version aufsetzen, sollte wohl eher umgestellt werden (eine spätere Umstellung würde vermutlich wohl noch mehr Zeit und Aufwand kosten). Jedoch muss alles gut überlegt sein.

Bei kleinen Tools und Anwendungen, die eventuell über das Internet zur Verfügung gestellt werden, gehen die Überlegungen eher in die Richtung, welche Framework-Version von den meisten Benutzern eingesetzt wird. Will man unbedingt ein aufregendes Design usw. führt ein Weg an WPF (und damit 3.0 bzw. 3.5) kaum vorbei.

Die Überlegungen sind also sehr zahlreich und eine allgemeine Antwort ist auf diese Frage nicht zu geben. Der Einzelfall muss hinterfragt und beleuchtet werden, dann ergibt sich auch eine entsprechende Antwort.
  1 Kommentar - 188 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


.NET BlogBook Ausgabe 6

14.04.08 - Entwicklung, Diskussionen, Patterns, Software Testing, Projektmgmt., Qualitätsmgmt., .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder
 Ab sofort steht die 6. Ausgabe des .NET BlogBooks zur Verfügung. Insgesamt stehen nun fast 330 Seiten an puren Informationen und Praxiswissen zur Verfügung.

Noch dazu wurden einige Anregungen aufgegriffen. Es gibt ein neues Cover (ein herzliches Dankeschön an 69° media solutions). Ebenfalls wurden unnötige dunkle Stellen entfernt, die beim Ausdrucken maximal Toner verbrauchen, sonst jedoch keinerlei Wirkung erzielen.

Hauptsächlich wurde das BlogBook um Wissen rund um die Windows Presentation Foundation erweitert, aber auch andere Punkte kamen hinzu. Ein Blick lohnt sich allemal.

Weitere Informationen sind auf der Homepage unter http://www.dotnet-blogbook.com zu finden.

Für Anregungen, Wünsche und (konstruktive) Kritik haben wir natürlich weiterhin ein offenes Ohr.
  6 Kommentare - 1363 mal angesehen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


WPF Teil 4: Fehlerbehandlung und Ressourcen

07.04.08 - .NET, Grundlagen, WPF
Beitrag von Norbert Eder
 Bisherige Teile:
WPF Teil 1: Die Windows Presentation Foundation aus der Sicht eines Unternehmens
WPF Teil 2: Windows Presentation Foundation oder doch lieber Windows Forms?
WPF Teil 3: Das Softwaredesign will gut überlegt sein

Bereits im dritten Teil wurde besprochen, dass natürlich die Anforderungen ein sehr wichtiges Thema sind und erst darauf aufbauend ein Design entwickelt werden kann. Nun ist ein Softwaredesign jedoch noch nicht alles. Weitere Punkte müssen unbedingt beachtet werden, um nicht später doch noch vor einem Problem zu stehen.

Einführung


Wie in allen Anwendungen (unabhängig, welche Technologien eingesetzt werden) sind Vorarbeiten notwendig, damit das Ergebnis den Wünschen entspricht. Dazu gehören unterschiedliche Dinge, unter anderem:
  • Fehlerbehandlung
  • Anpassbarkeit (Customization)
  • usw.

Gerade diese Punkte können durch ein Softwaredesign nicht 100%ig (bzw. teilweise gar nicht) abgedeckt werden. Jedoch ist es unablässig, diesen Bereichen vor dem Start der Implementierung die notwendige Beachtung zu schenken. Hier soll auf diese Punkte näher eingegangen werden.

Globale Fehlerbehandlung


Fehler treten in jeder Anwendung und in jeder Library auf und müssen entsprechend behandelt werden. Kommt es bei der Framework-Entwicklung vor, dass teilweise Exceptions nicht behandelt werden (da dies vom Verwender vorgenommen werden sollte), ist es bei einer Anwendung, die mit Benutzern zu tun hat, erforderlich, dass alle Fehler abgefangen werden.

Hierzu ist zu entscheiden, welche Fehler der Benutzer tatsächlich zu Gesicht bekommen sollte und welche nicht. Nicht bis zum Benutzer vordringen sollten Exceptions, die vom Benutzer nicht beeinflusst bzw. behoben werden können und von interner Natur sind. Diese sollten in einen Logging-Mechanismus landen, dessen Einträge über ein Incident Management an den Hersteller übertragen werden können.

Treten Fehler (auf Basis von Fehleingaben etc.) auf, die für den Anwender von Relevanz sind, müssen diese den Benutzer entsprechend darauf hinweisen - und das in einer verständlichen und übersichtlichen Form. In diesen Fällen reicht es meist nicht, nur die Message-Eigenschaft einer Exception anzuzeigen.

Da grundsätzlich nicht alle Fehler abgefangen werden (können) bietet sich zudem ein globales Exception-Handling an. Dieses kann in der WPF sehr einfach realisiert werden:

Zu diesem Zwecke ist das Application.DispatcherUnhandledException-Event vorgesehen. Dieses kann entweder via XAML in der App.xaml angegeben werden (der Eventhandler befindet sich in der Codebehind-Datei), oder vollständig in der App.xaml.cs. Der Eventhandler würde wie folgt aussehen:
private void Application_DispatcherUnhandledException(
    object sender, DispatcherUnhandledExceptionEventArgs e)
{
    LoggingManager.GetLog().Error(e.Exception);
    LoggingManager.GetLog().Debug(
        CultureInfo.CurrentCulture, 
        Environment.StackTrace);
}

In diesem Beispiel sorgt ein LoggingManager dafür, dass die Meldungen entsprechend aufgezeichnet werden, um zu einem späteren Zeitpunkt ausgewertet zu werden. Eine Erweiterung wäre hier, die möglichen Exceptions auszuwerten und gegebenenfalls gesondert darauf zu reagieren.

Ressourcen-Behandlung


Wie mit Ressourcen umgegangen wird, hängt sehr stark davon ab, wo und wie die resultierende Anwendung eingesetzt wird. Für eine rein interne Lösung, die für die Konfiguration von internen Systemen verwendet wird, haben Ressourcen meist keine sehr große Bedeutung. Bei Kundenprojekten sieht es schon anders aus.

Ressourcen können unterschiedlichste Dinge beinhalten: Unterschiedliche Sprachen, Grafiken, Konfigurationen, Templates, Styles und anderes ist möglich. Zu entscheiden ist in den einzelnen Fällen, was von externer Stelle manipulierbar sein soll und darf.

Wie bereits angesprochen, ist das Thema Aussehen und Usability bei kleinen internen Anwendungen meist nicht von Bedeutung. Jedoch bedeutet "intern" nicht unbedingt, dass die Anwendung nur von einem kleinen Personenkreis (z.B. nur Entwickler) verwendet wird. Ist dem der Fall gelten die gleichen Regeln wie für externe Anwendungen.

Bei externen Anwendungen gilt zu definieren, ob es sich dabei um Standard-Anwendungen handelt, oder um Grundgerüste, die auf den jeweiligen Kunden hin angepasst werden. Im ersteren Fall wird das Design meist vorgegeben und muss normalerweise nicht geändert werden. Vielmehr möchte man die Anwendung vor Änderungen schützen. Hierzu bietet es sich an, die Ressourcen zu integrieren. Im zweiteren Fall werden nicht nur spezifische Funktionalitäten für den Kunden entwickelt, sondern es müssen auch Anpassungen an die jeweilige Corporate Identity (CI) durchgeführt werden.
Da hierbei eventuell auch Änderungen am Aussehen, an der Platzierung der Elemente etc. direkt vor Ort vorgenommen werden können (ohne einen Entwickler bemühen zu müssen, oder weil der Kunde selbst Anpassungen durchführen möchte) bietet es sich an, die Ressourcen nicht in die Anwendung zu kompilieren, sondern extern zur Verfügung zu stellen.

Dies kann in der WPF bequem mit Hilfe von ResourceDictionaries durchgeführt werden. Damit ist es möglich, Ressourcen aus Dateien einzubinden. Diese Dateien können in einem eigenen Verzeichnis ausgelagert sein und werden von dort eingebunden. Diese ResourceDictionaries können nun beispielsweise Styles und Templates für Elemente beinhalten (sowohl für einzelne Elemente als auch global wirkend). Damit ist das Aussehen einfach steuerbar.

Zu beachten ist weiters, wie die Ressourcen eingebunden werden. Dies kann grundsätzlich auf zwei Arten passieren:

Der Unterschied dieser beiden Markup Extensions liegt darin, wie die Ressourcen geladen werden. Wird eine Ressource statisch gebunden, wird die Ressource beim ersten Zugriff darauf ausgewertet und auf das jeweilige Element angewandt. Bei der dynamischen Ressource kann sich die Ressource zur Laufzeit ändern. Das bedeutet, dass WPF selbst bestimmt, wann die Ressource neu eingelesen und angewandt werden muss.

Mit diesem Wissen gilt es nun zu entscheiden, wann welche Strategie zum Zug kommen soll. Als Faustregel: Was sich zur Laufzeit nie ändert, sollte als statische Ressource eingebunden werden. Was sich ändern kann, dynamisch. Generell sollte man mit dynamischen Ressourcen aber sparsam umgehen, da dies durchaus eine Auswirkung auf die Performance haben kann.

Fazit


Bevor die Implementierung eine Anwendung beginnt, sind zahlreiche Dinge zu klären. Fehlerbehandlung und Umgang mit den Ressourcen ist nur ein kleiner Teil davon. Doch gerade in diesem Bereich finden sich immer wieder Probleme in diversen Anwendungen bzw. Projekten. Klären Sie diese Punkte und etwaige Probleme werden sich zunehmends minimieren.
  Kommentar hinzufügen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Code Analysis und von WPF generierter Code

07.04.08 - Entwicklung, Diskussionen, .NET, Grundlagen, WPF
Beitrag von Norbert Eder
 Die lokale Code Analyse durch Visual Studio 2008 ist eine sehr hilfreiche Sache, um oft gemachte Unschönheiten, eventuelle Performance- und/oder Security-Probleme früh zu erkennen oder auch nur, um die korrekte Namensgebung zu beachten.

Werden die Richtlinien aktiviert (unter den Projekteigenschaften) und zudem einige dieser Richtlinien auf Error gestellt (standardmäßig sind alle als Warnings eingetragen), dann ist man gezwungen, eben diese auch tatsächlich zu beheben. Kein schlechter Weg, um die Qualität des Codes früh auf einen entsprechenden Standard zu heben.

Allerdings gibt es dabei auch einen Haken:
Es gibt die Möglichkeit, generierten Code von der Überprüfung auszunehmen. Dies ist sehr sinnvoll, wenn Code von 3rd-Party-Tools generiert wird und es keine Möglichkeit gibt, die Generierung zu beeinflussen d.h. etwaige Warnings oder Errors los zu werden. Dies kann in den Projekt-Eigenschaften eingestellt werden:



Die WPF selbst generiert ja aus dem definierten XAML im Hintergrund den notwendigen Sourcecode. Wird ein neues Fenster angelegt, besteht dieses aus zwei Dateien:

- Window1.xaml
- Window1.xaml.cs

In der Window1.xaml kann nun per XAML Markup die einzelnen Elemente definiert werden. WIndow1.xaml.cs ist die Codebehind-Datei und enthält den notwendigen Sourcecode (Eventhandler etc.). Nun muss aus der XAML-Datei einiges an Code generiert werden:
  • Deklaration der einzelnen Elemente, damit via Sourcecode darauf zugegriffen werden kann.
  • Methode InitializComponent
  • Methode Connect

All das landet in der Datei Window1.g.cs. Wird also im Hintergrund für uns generiert. (Daher das g in der Endung). Blöderweise erhält diese Datei kein GeneratedCodeAttribute, wodurch die Prüfung auf die Richtlinien hin unterdrückt werden würde.

Im zu Grunde liegenden MSDN-Beitrag findet sich auch kein Hinweis darauf, schließlich wird WPF dort auch noch gar nicht behandelt.

Der einzige Ausweg daraus ist, den erhaltenden Fehler per SuppressMessage auszuklammern und zwar global für den gesamten Namespace. Eine Ausklammerung direkt im Source würde keine dauerhafte Änderung bringen, da das SuppressMessage-Attribute bei der nächsten Generierung überschrieben werden würde.

Hier sollte wohl noch etwas gemacht werden ...

  Kommentar hinzufügen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


Das .NET BlogBook bricht die 20.000 Downloads-Schallmauer

02.04.08 - Blog-Intern, .NET, Grundlagen, Base Framework, WPF, ASP.NET, Silverlight, Mobile Devices, Datenverwaltung, Visual Studio, Allerlei, Microsoft Office, SQL Server
Beitrag von Norbert Eder
 Kürzlich wurde der 20.000ste Download vom .NET BlogBook vollführt. Für mich als Herausgeber ist dies natürlich eine große Freude. Schließlich existiert das .NET BlogBook erst seit knapp mehr als einem Jahr.

Das gibt natürlich Motivation für weitere Anpassungen, Ergänzungen und natürlich Verbesserungen.

Vielen Dank auch an alle Leser, die das Team mit Rückmeldungen motivieren oder Verbesserungen anregen.

Danke!

  1 Kommentar - 781 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


WPF: Array-Bug oder ist das so gewollt?

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):
<Window.Resources>
    <Style TargetType="TextBlock">
        <Setter Property="HorizontalAlignment" Value="Center" />
        <Setter Property="FontFamily" Value="Comic Sans MS"/>
        <Setter Property="FontSize" Value="14"/>
    </Style>

    <x:Array x:Key="MyPhotos" Type="{x:Type sys:String}">
        <sys:String>Blaue Berge.jpg</sys:String>
        <sys:String>Sonnenuntergang.jpg</sys:String>
        <sys:String>Winter.jpg</sys:String>
    </x:Array>
</Window.Resources>

<StackPanel Orientation="Vertical">
    <TextBlock Name="textblock1">My Pictures</TextBlock>
    <TextBlock>Check out my new pictures!</TextBlock>
    <ListBox 
        x:Name="PhotoBox" 
        Background="Silver" 
        SelectedIndex="0" 
        ItemsSource="{Binding Source={StaticResource MyPhotos}}"/>
</StackPanel>

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:
<Window.Resources>
    <x:Array x:Key="MyPhotos" Type="{x:Type sys:String}">
        <sys:String>Blaue Berge.jpg</sys:String>
        <sys:String>Sonnenuntergang.jpg</sys:String>
        <sys:String>Winter.jpg</sys:String>
    </x:Array>

    <Style TargetType="TextBlock">
        <Setter Property="HorizontalAlignment" Value="Center" />
        <Setter Property="FontFamily" Value="Comic Sans MS"/>
        <Setter Property="FontSize" Value="14"/>
    </Style>
</Window.Resources>

<StackPanel Orientation="Vertical">
    <TextBlock Name="textblock1">My Pictures</TextBlock>
    <TextBlock>Check out my new pictures!</TextBlock>
    <ListBox 
        x:Name="PhotoBox" 
        Background="Silver" 
        SelectedIndex="0" 
        ItemsSource="{Binding Source={StaticResource MyPhotos}}"/>
</StackPanel>


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.

Eigentlich verwirrend, oder nicht?
  2 Kommentare - 2181 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL



Zurück Weiter