Nervig hoch 2: FxCop + WPF
14.05.08 - Entwicklung, Qualitätsmgmt., .NET, Windows Forms/WPF Beitrag von Norbert Eder| | Ein Großteil des FxCop Ruleset ist bei meinen Projekten ständig aktiviert und hilft so, den Code sauberer, sicherer und performanter zu halten.
Aber gerade in Kombination mit WPF ergeben sich daraus natürlich einige Probleme oder besser gesagt, Ärgernisse. Nehmen wir die Regel CA1823. Diese besagt, dass ein Feld nicht verwendet wird, oder ihm nie ein Wert zugewiesen wurde. Derartige Regeln werden bei mir grundsätzlich als Fehler und nicht als Warnung behandelt.
Wie kommt man nun dazu, sich über diesen Fehler zu ärgern? Ganz einfach. Man vergebe einem Element einen x:Name. Dadurch wird es im generierten File (.g.cs) angelegt, damit aus der Codebehind-Datei darauf zugegriffen werden kann. Eventuell möchte man dies jedoch nicht, sondern vergibt dem Element bloß einen Namen, um per Binding darauf zuzugreifen.
Und schon taucht dieser Fehler auf und schreit nahezu danach, suppressed zu werden - was ja eigentlich vermieden werden sollte.
Wäre schön, wenn sich diesbezüglich zukünftig etwas tun würde ..
| | | 2 Kommentare
- 73 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Gewinnspiel auf .NET GUI verlängert
13.05.08 - .NET, Windows Forms/WPF, ASP.NET, Silverlight, Visual Studio, Allerlei, Internet, Community Beitrag von Norbert Eder| | Der Annahmeschluss für das aktuell laufende Gewinnspiel auf .NET GUI wurde bis 16. Mai 2008 verlängert. Alle Artikel, die bis Mitternacht eingehen, werden für das Gewinnspiel berücksichtigt.
Noch ein kleiner Hinweis: Die Artikel müssen sich nicht zwangsweise um WPF und XAML drehen. Alles rund um .NET und GUI kann als Grundlage dienen (Windows Forms, GDI+, ASP.NET etc.)
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Visual Studio 2008 SP1: Was bringt es für WPF?
08.05.08 - .NET, Windows Forms/WPF, Visual Studio Beitrag von Norbert Eder| | Im Service Pack 1 zu Visual Studio 2008 wird es einige Änderungen bzw. Erweiterungen zum Thema WPF geben. Eine genaue Übersicht gibt diese Veröffentlichung von Microsoft.
Hier eine Liste der neuen Funktionalitäten:
- The Properties window now contains the Events tab. The Events tab lets you create events, assign events, and review events.
- The Properties window now includes a category sort option and an alphabetical sort option to allow for faster property location.
- Code changes have been made to the XAML Refactor/Rename definition and to the Go to definition. These changes allow XAML rename operations to occur automatically. Additionally, you can navigate the XAML definition by pressing F12.
- You can now drag controls or create controls from the toolbox in XAML view or in Design view. You can do this even if you use a split view configuration.
- Snaplines are now implemented for control margins. This lets the designer control a fixed distance from other controls, from container edges, or from gridlines.
- Tab controls now support TabItem activation and TabItem design. To do this, click the tab that you want to design.
- The Expander control now expands conditionally based on what is selected. You can design the contents of the Expander control at design time with affecting the IsExpanded attribute of the runtime.
Im Paket sind also durchaus Features, die bereits zu Beginn dabei hätten sollen. Vor allem Umbenennungen waren bisher ein wahrer Graus.
Einiges dürfte mit diesem SP1 zukünftig leichter fallen, dennoch fehlen mir immer noch ein paar Punkte, die hauptsächlich nur Bug-Fixes behoben werden können. Dieses SP bietet jedoch nur Erweiterungen und Verbesserungen an, keine Bug-Fixes ...
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
WPF und Master Pages
07.05.08 - .NET, Windows Forms/WPF, ASP.NET Beitrag von Norbert Eder| | Wer bereits mit ASP.NET in Berührung kam, der kennt eventuell die Master Pages. Also eine Art Vorlage, die das grundsätzliche Aussehen aller darauf basierenden Seiten beschreibt. Vorhandene Platzhalter können je nach Seite mit dem gewünschten Inhalt befüllt werden.
Dieses Verhalten wäre in einigen Fällen auch für WPF sehr hilfreich. Leider gibt es diese in dieser Form nicht. Wie ein derartiges Verhalten jedoch trotzdem simuliert werden kann, zeigt der Artikel WPF "Master Page" like functionality von Brad Cunningham
Empfehlenswert!
Edit: Ebenfalls sehr empfehlenswert ist der Artikel von Karin Huber auf CodeProject zu diesem Thema: WPF Master Pages.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Deaktivierte Buttons und Margin-Verhalten
06.05.08 - .NET, Windows Forms/WPF Beitrag von Norbert Eder| | Wer ein StackPanel mit Buttons á la Visual Studio Toolbox entwickelt, der möchte eventuell diese contextsensitiv anzeigen. Eine Variante ist, alle Elemente zu laden und je nach Bedarf aus- bzw. einzublenden.
Dies in einem Window nachgestellt, könnte in etwa wie folgt per XAML definiert sein:
<Window.Resources>
<Style TargetType="Button">
<Setter Property="SnapsToDevicePixels" Value="true"/>
<Setter Property="OverridesDefaultStyle" Value="true"/>
<Setter Property="MinHeight" Value="0"/>
<Setter Property="MinWidth" Value="75"/>
<Setter Property="Margin" Value="10"/>
<Setter Property="Template">
<Setter.Value>
<ControlTemplate TargetType="Button">
<Border x:Name="Border"
Background="Beige"
CornerRadius="2"
BorderThickness="1"
BorderBrush="Brown">
<ContentPresenter
Margin="2"
HorizontalAlignment="Center"
VerticalAlignment="Center"
RecognizesAccessKey="True"/>
</Border>
<ControlTemplate.Triggers>
<Trigger Property="IsVisible" Value="false">
<Setter Property="Height" Value="0"/>
</Trigger>
</ControlTemplate.Triggers>
</ControlTemplate>
</Setter.Value>
</Setter>
</Style>
</Window.Resources>
<StackPanel>
<Button x:Name="Button1"
Content="Button1"/>
<Button x:Name="Button2"
Content="Button2"/>
<Button x:Name="Button3"
Content="Button3"/>
<Button x:Name="SetButton"
Content="Toggle Button1 Un/Visible"
Click="SetButton_Click" />
<Button x:Name="CheckButton"
Content="Check Height"
Click="CheckButton_Click"/>
</StackPanel>
Und so sieht es aus:
Damit die Buttons nicht aneinander kleben, wurde ein entsprechender Margin gesetzt. Nun soll (in diesem Beispiel) ein bestimmter Button ausgeblendet werden. Dies wird mit Hilfe eines anderen Buttons erledigt:
private void SetButton_Click(object sender, RoutedEventArgs e)
{
if (Button2.Visibility == Visibility.Visible)
Button2.Visibility = Visibility.Hidden;
else
Button2.Visibility = Visibility.Visible;
}
Soweit auch noch keine Tragik.
Wird nun der Button ausgeblendet, dann erhält man folgendes Ergebnis:
Eigentlich nicht ganz das, was man sich erwartet. Es wurde zwar der Button ausgeblendet, aber der definierte Margin ist nach wie vor vorhanden. Meiner Meinung nach, sollte der Margin ebenfalls ausgeblendet werden, so er denn logisch zum Button gehört.
Zu beachten ist der Trigger auf IsVisible im ContentTemplate, der die Höhe des Buttons auf 0 setzt, damit nicht nur der Button ausgeblendet wird, sondern der Zwischenraum durch die restlichen Buttons aufgefüllt wird.
Damit auch der Margin ausgeblendet wird, muss dieser im Trigger explizit auf 0 gestellt werden:
<Trigger Property="IsVisible" Value="false">
<Setter Property="Height" Value="0"/>
<Setter Property="Margin" Value="0"/>
</Trigger>
Nun erhält man das gewünschte Ergebnis:
PS: Schelm, wer Böses denkt und ein WrapPanel empfiehlt. Ist auch hier dasselbe.
| | | 1 Kommentar
- 36 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 |
WPF ist so extrem kompliziert ...
30.04.08 - Entwicklung, Diskussionen, .NET, Windows Forms/WPF Beitrag von Norbert Eder| | ... liest man so immer wieder in allen Foren, die sich auch nur annähernde mit der Thematik beschäftigen. Das ist auch durchaus korrekt - zumindest zu Beginn.
Dadurch, dass sich sehr viele Konzepte geändret haben und natürlich jede Menge neues hinzukam, hat sich die Entwicklung von grafischen Oberflächen drastisch geändert. Das resultiert natürlich darin, dass die Lernkurve eine viel steilere ist und zudem viel vorhandenes Wissen verworfen werden muss.
Aber bei Windows Forms konnte ich das immer so machen. Oder so ähnlich lesen sich Beiträge. Mein Rat: Vergesst, was ihr von Windows Forms kennt. Anders ist es kaum zu formulieren.
Windows Forms war gestern (ganz so drastisch ist es nicht, aber aus Sicht der Vision von WPF dann doch wieder). Es ist wichtig die neuen Konzepte zu erfassen und sie verstehen zu lernen. Erst dann sind erste erfolgreiche Schritte tatsächlich möglich.
Es ist nicht bloß die Trennung zwischen Präsentation und Logik, die WPF als neuartig erscheinen läßt. Nein, WPF verwendet teilweise auch Techniken, die schon zig Jahre alt sind. Eben eine Mischung aus GDI/GDI+, Web, Windows Forms usw. Das alles auf Basis von DirectX und noch dazu mit einem unterschiedlichen Rendering-Mechanismus.
Es haben sich nicht nur die Möglichkeiten verändert, nein. Auch Gedanken müssen anders gedacht werden. Andere Schritte als bisher führen zum Ziel. Vieles erscheint im ersten Moment als sehr kompliziert, zeigt aber erst nach einer gewissen Einarbeitungsphase den wahren Reiz und die wahren Möglichkeiten. Wer über die ersten Frust-Momente hinweg kommt, der hat es geschafft.
Daher all denjenigen, die sich selbst in Frage stellen, denen ich in diversen Foren Mut machen konnte oder diejenigen, die diesbezüglich eine Aussage von mir per Mail "eingefordert" haben: Versucht die Konzepte dahinter zu verstehen und befreit euch vom Gedanken, wie es denn unter Windows Forms funktionieren würde ...
| | | 2 Kommentare
- 116 mal angesehen
| 0 Trackbacks
| Permalink | Trackback-URL |
Webgrafik einfach und schnell mit WPF anzeigen
29.04.08 - .NET, Windows Forms/WPF, ASP.NET Beitrag von Norbert Eder| | Wie geht man ans Werk, wenn in einer WPF-Anwendung Grafiken aus dem Internet geladen und angezeigt werden sollen? Nun ja, herunterladen, zwischenspeichern (Dateisystem, oder Arbeitsspeicher), eine BitmapSource erstellen und dann der Source eines Image-Elementes zuweisen.
Aber das geht auch einfacher!
private void HandleImage(Image image, Uri webUri)
{
BitmapDecoder bDecoder = BitmapDecoder.Create(
webUri,
BitmapCreateOptions.PreservePixelFormat,
BitmapCacheOption.None);
if (bDecoder != null && bDecoder.Frames.Count > 0)
image.Source = bDecoder.Frames[0];
}
Das ist auch schon alles was man tun muss. Stichwort ist der BitmapDecoder. Dieser bekommt in der statischen Methode Create ein Uri-Objekt (daher muss es nicht umbedingt ein Image im Web sein) übergeben. Wenn alles gut geht, können wir das Resultat aus der Frames-Auflistung beziehen und zur Anzeige bringen.
So einfach, wenn man weiß wie ;-)
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL |
Visual Studio 2008 Feature Matrix
29.04.08 - .NET, Visual Studio Beitrag von Norbert Eder
Na? Welche .NET Framework-Version darf es denn sein?
28.04.08 - .NET, Grundlagen, Base Framework, Windows Forms/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.
| | | Kommentar hinzufügen
| 0 Trackbacks
| Permalink | Trackback-URL | Weiter
|
|
|
|
|
|
|