.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

Heute schon gewonnen?

20.04.08 - .NET, WPF, Internet, Community
Beitrag von Norbert Eder
  Nein? Dann aber nichts wie los! Gewinnen kann sehr einfach sein. So bietet .NET GUI ab sofort die Möglichkeit, ein glücklicher Gewinner zu sein.

Unter dem Motto Mit .NET GUI gewinnen wird bis einschließlich 15. Mai 2008 eine Lizenz von Infragistics NetAdvantage for WPF im Wert von fast 800$ verlost.

Also nichts wie ran. Teilnehmen und gewinnen!

Weitere Informationen unter: http://dotnet-gui.com/forums/t/70.aspx
  1 Kommentar - 222 mal angesehen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Diagramm-Designer mittels WPF erstellen

19.04.08 - .NET, WPF
Beitrag von Norbert Eder
 Gerade wenn es um einen Diagramm-Designer geht, stellt WPF eine wunderbare Wahl dar. Diese Entscheidung hatte ich auch schon vor einigen Monaten getroffen und das umgesetzte Projekt erfreut sich regelmäßiger Verwendung.

Wer nun ebenfalls einen Diagramm-Designer erstellen muss/möchte, den möchte ich auf die folgende Ressourcen verweisen:

WPF Diagram Designer: Part 1
WPF Diagram Designer: Part 2
WPF Diagram Designer: Part 3
WPF Diagram Designer: Part 4

In diesen Artikeln inkl. Sourcecode sollten recht viele Fragen beantwortet werden und der Umsetzung eines derartigen Projektes steht wohl nichts mehr im Wege. Viel Spaß.

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


Auf .NET GUI tut sich was!

16.04.08 - Blog-Intern, .NET, WPF, ASP.NET, Silverlight, Visual Studio, Allerlei
Beitrag von Norbert Eder
  Ja, richtig gelesen. Auf .NET GUI tut sich was. In den letzten Tagen wurden einige Verbesserungen vorgenommen, welche den Besuchern und Mitgliedern zu Gute kommen sollen und hoffentlich auch werden. Es ist ein erklärtes Ziel, eine optimale Plattform für GUI-Entwickler/-Designer zu schaffen und daher werden wir uns diesem Ziel Schritt für Schritt nähern.

Hier nun eine kurze Auflistung der neuen Features/Funktionen:

Ressourcen-Liste
Ressourcen sind eine wichtige Sache, wenn man sich in ein Thema einarbeiten möchte oder spezielle Informationen sucht. In der angebotenen Ressourcen-Liste werden hilfreiche Links angeboten, die sowohl dem Entwickler, als auch dem Designer bei der täglichen Arbeit unterstützen sollen.

Coders Lounge
Damit auch allgemeine Programmierthemen ihren Platz finden, wurde die Coders Lounge eingeführt. Hier kann über alles Mögliche und Unmögliche zum Thema Programmierung/Entwicklung diskutiert werden.

Verbesserter Editor
Der verfügbare Editor zum Schreiben von Beiträgen wurde gegen einen neuen Editor mit verbesserten Funktionen ausgetauscht. Damit können Beiträge noch einfacher geschrieben und übersichtlicher gestaltet werden.

Browser-Suche
Wer die Browsersuche unter Firefox bzw. Internet Explorer 7 gerne und häufig verwendet, kann nun den Provider von .NET GUI installieren und damit bequem diese Community durchsuchen.

Verbesserte Erreichbarkeit
Ab sofort ist .NET GUI nicht nur via http://dotnet-gui.com, sonder zusätzlich über http://dotnet-gui.at und http://dotnet-gui.net.

Es hat sich also viel getan und weitere Funktionalitäten sind bereits in Planung. Man darf gespannt sein.

Wer Teil dieser Community werden möchte kann sich natürlich jederzeit gerne registrieren.
  2 Kommentare - 1094 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 - 1356 mal angesehen   |  1 Trackbacks   |  Permalink  |  Trackback-URL


Code-Only Anwendungen mit WPF entwickeln

14.04.08 - .NET, WPF
Beitrag von Norbert Eder
 Eine WPF-Anwendung muss nicht immer mit Hilfe von XAML geschrieben werden, auch ohne XAML kann eine WPF-Anwendung erstellt werden. Warum dies notwendig ist könnte mehrere Gründe haben, der wohl oft vorkommendste: XAML ist nicht bekannt und es fehlt die Einarbeitungszeit. Eine andere Möglichkeit besteht natürlich auch darin, dass zur Laufzeit ein Fenster dynamisch erstellt werden sollen.

Wie ist also vorzugehen: Grundsätzlich kann eine ganz normale WPF-Anwendung erstellt werden. Die Dateien App.xaml und Window1.xaml sind anschließend zu löschen (die Codebehind-Dateien werden automatisch mit gelöscht). Der Vorteil dieser Variante liegt darin, dass die notwendigen Referenzen alle dem Projekt hinzugefügt werden und somit diesbezüglich keinerlei Aufwand entsteht (natürlich kann dies auch manuell geschehen).

Wer dies manuell machen möchte, muss folgende Referenzen seinem Projekt hinzufügen:
  • PresentationCore
  • PresentationFramework
  • WindowsBase


Nun wird im ersten Schritt eine neue Klasse App.cs dem Projekt hinzugefügt. Diese erbt von Application und enthält den notwendigen Einstiegspunkt.
public class App : Application
{
    [STAThread]
    static void Main(string[ args) 
    {
        Application app = new Application();
        app.Run(new MainWindow());
    }
}

Im Grunde passiert nichts anderes, als dass eine neue Application-Instanz erstellt wird und deren Methode Run aufgerufen wird. Als Parameter erhält sie eine Instanz des Typs MainWindow. MainWindow ist so aktuell noch nicht verfügbar, werden wir jedoch im nächsten Schritt erstellen.
public class MainWindow : Window
{
    StackPanel mainPanel = null;
    Label label1 = null;
    Button button1 = null;

    private void InitializeComponent()
    {
        mainPanel = new StackPanel();
        mainPanel.Name = "MainPanel";
        mainPanel.Orientation = Orientation.Vertical;

        label1 = new Label();
        label1.Content = "Code Only App";
        label1.FontSize = 18;

        button1 = new Button();
        button1.Content = "Close";

        mainPanel.Children.Add(label1);
        mainPanel.Children.Add(button1);

        this.Content = mainPanel;
    }

    public MainWindow()
    {
        InitializeComponent();

        Init();

        button1.Click += 
        new RoutedEventHandler(button1_Click);
    }

    void button1_Click(
        object sender, 
        RoutedEventArgs e)
    {
        Application.Current.Shutdown(0);
    }

    private void Init()
    {
        this.Title = "Code Only App";
        this.Height = 300;
        this.Width = 300;
    }
}

Die Klasse MainWindow.cs erbt von Window und stellt unser Hauptfenster dar. Wie zu sehen ist, werden nun lediglich durch Code (kein XAML) die einzelnen anzuzeigenden Elemente erstellt. Sämtliche Methoden wurden manuell erstellt, d.h. es gibt hier keinen Code, der irgendwie automatisch erstellt wurde.

Das Ergebnis kann in der nachfolgenden Grafik bewundert werden. Natürlich kann auf diese Variante ebenfalls ein hübsches Design erzeugt werden. Diese Demo sollte jedoch nur grundsätzlich zeigen, wie Code-Only-Applikationen erstellt werden können.



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


Wir Österreicher sind nicht nur ...

14.04.08 - Kunterbunt
Beitrag von Norbert Eder
 ... beim Skifahren Weltklasse. Gestern wurde eindrucksvoll bewiesen, dass wir auch Schwimmen können - oder zumindest ein paar unserer Landsleute. So muss man Markus Rogran zu seinem Weltmeistertitel über 200m Rücken gratulieren und das noch mit der Weltrekordzeit von 1:47,84. Eindrucksvoll.

Man muss sich eben andere Sportarten suchen, wenn man beim Fußball nichts zusammen bringt ;-) Ergo muss wohl auch bald bei den Eishockey-A-Teams das große Zittern beginnen...
  2 Kommentare - 843 mal angesehen   |  0 Trackbacks   |  Permalink  |  Trackback-URL


dotnet-gui.com: Neue Community für grafische Oberflächen unter .NET

11.04.08 - Blog-Intern, .NET, WPF, ASP.NET, Silverlight, Allerlei, Internet, Community
Beitrag von Norbert Eder
  Seit gestern steht eine neue Community rund um .NET zur Verfügung. Halt nein! Dabei handelt es sich nicht schon wieder um eine gewöhnliche .NET Community. Vielmehr beschäftigt sich dotnet-gui.com mit der Entwicklung von grafischen Oberflächen auf Basis des .NET Frameworks und allen Erweiterungen. Dies inkludiert unter anderem folgende Bereiche:
  • Windows Forms
  • Windows Presentation Foundation
  • Silverlight
  • Usability
  • Werkzeuge
  • und mehr

Erklärtes Ziel ist es, eine Community zu schaffen, die kompetente Hilfestellungen sowohl an Einsteigern und Fortgeschrittenen leisten kann. Weiters sollen konstruktive Diskussionen zu den einzelnen Bereichen unter Gleichgesinnten ermöglicht werden.

Weitere Informationen sind direkt unter dotnet-gui.com verfügbar.

  7 Kommentare - 1037 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


Einer dieser Tage ...

07.04.08 - Kunterbunt
Beitrag von Norbert Eder
 Diese Woche hat heute in der Früh schon sehr gut begonnen. Da wollte ein Dokument per Email versendet werden. Also, schnell mal eben Zippen (Office-Dokumente, Grafiken, etc.). Just im Moment der Zipperei vertschüsst sich der Rechner. Kein Problem. Neu gestartet, Files vor dem erneuten Zippen nochmals kontrolliert und was ist? Office-Dokument kaputt. Na toll. Und in der letzten Sicherung sind gestern spät abends vorgenommene Änderungen noch nicht drinnen. Juhu.

Merke:
1. Vor dem Zippen, die zu zippende Dateien sichern!
2. Sicherung anwerfen, selbst wenn man vorm PC spät abends schon fast einschläft!

Narf. SSKM.

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



Zurück Weiter