Benjamin Gopp (HiQ-Software)

VS2010 Extension: ZoomEditorMargin

2009-10-20T15:27:00.005+01:00

VS2010 Beta2 ist endlich draußen. Kaum heruntergeladen und installiert, habe ich auch schon die erste Erweiterung für den neuen WPF Codeeditor geschrieben!

Besonders gespannt war ich auf die Zoom Funktion des Codeeditors. Als ich VS2010 zum ersten Mal öffnete, war ich jedoch etwas enttäuscht. Auf der linken Seite des Code Editors befand sich lediglich eine Combobox, über die man den Zoom einstellen kann. Aus meiner Erfahrung mit Office 2007, hätte ich jedoch gerne einen Slider gehabt, mit dem ich stufenlos zoomen könnte.

Zum Glück lässt sich der neue WPF Codeeditor in VS2010 an allen Ecken und Enden anpassen. Gesagt getan, habe ich eine eigene "Margin" für den Editor geschrieben. Eine Margin ist ein Bereich im Codeeditor, in dem man ein WPF Control platzieren kann. Dies ist nur eine von vielen Möglichkeiten den Codeeditor anzupassen und zu erweitern.

Wer das ZoomEditorMargin herunterladen und direkt ausprobieren möchte, kann dies in der , oder über den ExtensionManager in VisualStudio tun.

Der Code Editor ohne Zoom Extension

Der Code Editor mit Zoom Extension

In den nächsten Posts werde ich erklären, wie ich diese Extension erstellt habe. Es gibt viele Aspekte, auf die ich näher eingehen möchte. Deswegen verrate ich nicht alles schon in diesem Blog Post.

Viel Spaß und stay tuned

Benny

Stirnrunzeln über: "Stirnrunzeln über das Neuste von Microsoft seit geschnitten Brot"

2009-10-15T09:41:00.002+01:00

Ralf Westphal schrieb in seinem Blog "Stirnrunzeln über das Neuste von Microsoft seit geschnitten Brot", über das neue Reaktive Framework (Rx) von Microsoft. Zunächst wollte ich einen Kommentar in sein Blog schreiben. Der Kommentar ist dann etwas länger ausgefallen, so dass ich mich entschieden habe, einen eigenen Blog Eintrag mit meiner Meinung zu diesem Thema zu schreiben. Ralf fordert sogar zu Reaktionen auf: "Oder übersehe ich hier die eigentliche Erfindung? Geht der brillante Innovationshub an mir vorbei? Ich bitte um Erhellung"

Also versuch ich doch etwas Licht ins Dunkeln zu bringen.

Wo ist das Problem?!

Für Ralf besteht das Problem an dieser neuen Technologie, dass er ein "neues Vokabular für etwas Altes" benutzen muss. Nach dem Motto: Raider ist jetzt Twix. Klar, wenn etwas Neues mit einem alten Begriff besetzt ist und das Neue immer mit dem Alten assoziiert wird, sinkt natürlich die Akzeptanz für das Neue. Heißt das aber, dass da Neue schlecht ist? Das kann ich (noch) nicht beurteilen. Trotzdem bin ich Neuem erst mal aufgeschlossen eingestellt.

Was ist also das Alte? Für Ralf ist das Alte: Complex Event Processing (CEP).

"Das ist nicht neu, das ist kein Hexenwerk".

Aber das ist doch mit den meisten Erfindungen so! Irgendwo hat's Irgendwer bereits erfunden. Das Neue sieht nur hübscher aus: "es ist eben keine tolle neue Erfindung seit geschnitten Brot, sondern etwas lange Bekanntes in aufgehübschtes Gewand gekleidet". Ja, das ist vermutlich so.

"Tut mir leid, da ist nichts Neues für mich dabei. Wenn ich im etablierten Paradigma data flow denke, dann ist das etwas uraltes und kann mit heutigen Mitteln bewältigt werden."

Ralf, das mag für dich alles "kalter Kaffee" sein. Aber hallo? Data flow, etabliert? Wo denn bitte? In welcher Firma die Software Entwicklung ist denn dieses Paradigma etabliert? Frag doch aber bitte mal deine Kunden, die Teilnehmer der CCD Seminare, die Besucher einer Konferenz, die Zuhörer deiner Vorträge. Wer von denen:

hat von CEP, Esper oder CCR gehört?
hat einen Artikel über CEP, Esper oder CCR gelesen (von dir oder jemand anders)?
verwendet CEP, Esper oder CCR produktiv in seinen Buisiness Anwendungen?

Antwort: fast
Niemand.

Das ist das Problem: Für Dich und einige Wenige ist das alles Schnee von gestern (siehe 1. Kommentar von Holger Hofstätte). Für die breite Masse, absolutes Neuland.

"Wer das wirklich einmal ausprobieren will, was man mit einer Abfragesprache auf Event-Strömen tun kann, dann kann mit NEsper spielen"

Nein Ralf, ich will nichts ausprobieren, ich will auch nicht nur damit spielen. Ich möchte diese Funktionalität im .NET Framework haben und produktiv sein.

Reaktive Programmierung wird im Core .NET Framework vorhanden sein. Das ist das Neue! Das ist Etablierung!

Was ist mit LINQ

Zur Erinnerung: für Ralf besteht das Problem am Reactive Framework, dass es das alles schon einmal gab. Was war aber gleich nochmal LINQ?

Das Konzept hinter LINQ kommt aus der funktionalen Programmierung (Map, Filter, Reduce). Anscheinend hatte hier Ralf keine oder nicht genügend Berührungspunkte mit der funktionalen Programmierung, dass er automatsch LINQ mit einer längst erfundenen Technologie assoziiert hätte. Zumindest wird Erik Meijer für sein "Brainchild" LINQ gelobt, jedoch nicht für seine anderen Projekte (z.B: Volta und Rx).

Funktionale Programmierung war doch auch nur ein akademisches Thema. Vielleicht ist man im Studium mit LISP, ML oder Miranda in Berührung gekommen. Angekommen im Berufsleben hat man aber seine Daten über geschachtelte for-Schleifen gefiltert. Von wegen Map, Filter, Reduce. Obwohl die Technologie doch bereits in .NET vorhanden war (Delegates, Iteratoren). Trotzdem hat es keiner genutzt. Aber dann kam LINQ daher und mit ein bischen "syntactic sugar" für C#, etabliert sich ein Konzept aus der funktionalen Programmierung auch in einer objektorientierten Programmiersprache wie .NET. Und da das Konzept im Framework verankert ist, ist LINQ sogar für alle.NET basierten Programmiersprachen verfügbar.

Erst mit LINQ hat sich das funktionale Paradigma in der breiten Masse etabliert. Immer mehr Leute benutzen LINQ Queries um ihre Listen zu projizieren, filtern und aggregieren. Immer mehr Leute verwenden Lambda Ausdrücke für die alltäglichsten Dinge.

BetaMax vs. VHS, HD vs. BlueRay

LINQ hat da eine Tür aufgestoßen, das Reaktive Framework wird das gleiche machen und den Weg in den Mainstream finden

"Flows habe ich aber natürlich nicht erfunden. Die sind alt"... "Mainstream ist es aber nicht geworden, wie wir sehen. Schade. Denn die Schritte in einem Flow steigern die Evolvierbarkeit von Software, finde ich"

Ralf, das ist doch genau dein Wunsch, dass das Konzept den Weg in den Mainstream findet. Welche Technologie letztendlich das Rennen macht spielt doch keine Rolle. Ob BetaMax oder VHS, HD oder BlueRay, CEP oder Rx.

Fazit

Es gab schon immer Erfindungen, die nur einem kleinen elitären Bereich in Industrie und Forschung, zugänglich oder erschlossen waren. Nur weil es eine Technologie in einem kleinem Bereich Anklang gefunden hat, kann man nicht sagen die Technologie sei etabliert. Erst wenn sie es in den Mainstream geschafft hat, kann man von Etablierung sprechen. LINQ ist ein super Beispiel dafür, dass ein akademisches Thema dem Mainstream zugänglich wird.

CEP, Esper und CCR haben sich nicht etabliert und werden sich nicht etablieren.Das Reactive Framework wird sich aber etablieren. Warum? Ganz einfach, es wird Kernbestandteil von .NET sein und damit zugänglich und allgegenwärtig für .NET Entwickler. Kein separates Tool, kein irgendwo runterladen, kein rumspielen. Es wird einfach da sein. Bleibt nur noch es auch zu nutzen...

F# - Teil 1

2009-06-25T08:18:00.001+01:00

Vorgestern habe ich einen Vortrag bei der User Group Köln über F# gehalten. Dort habe ich über meine Erfahrungen mit F# geredet und ein paar Sprachfeatures gezeigt. Leider waren 30 Minuten viel zu wenig um alles zu zeigen und auch noch Fragen zu beantworten. In den kommenden Blogeinträgen werde ich daher meine Erfahrungen mit F# schriftlich festhalten.

F# ist eine neue Programmiersprache in der .NET Familie. Diese wird in VS2010 neben VB und C# eine der Hauptsprachen für die .NET Entwicklung werden; so der Plan.

Déjà-vu

Als ich zum ersten Mal die Beta1 von VisualStudio 2010 öffnete, hatte ich ein Déjà-vu Erlebnis. F# hatte ich bereits in VS2008 ausprobiert, aber erst mit VS2010 ist mir bewusst geworden, was Microsoft da eigentlich vor hat. Und dann lief es mir eiskalt den Rücken runter. Denn als ich zum ersten Mal vor ca. 6 Jahren ein VisualStudio 2003 installierte, um .NET zu lernen, stand neben VB und C# eine weitere Programmiersprache zur Auswahl; und das war J#.

Welchen Weg J# gegangen ist, muss ich nicht erwähnen. (Wer noch aktiv in J# programmiert, der möge sich bitte bei mir melden!). Könnte das gleiche Schicksal F# ereilen?

J# vs. F#

Die Frage ist, ob nur weil F# in VS2010 bereits vorinstalliert ist und man es sich nicht separat herunterladen muss, dieses dann auch öfters genutzt wird. Bei J# hat das ja auch nicht geholfen.

Nun, auf den ersten Blick hat F# ein schlechtes "Karma". Warum kann man aber doch sagen, das F# seinen Weg machen wird?

	J#	C#	F#
Paradigma	objektorientiert	objektorientiert	funktional
Sprachfamilie	C	C	ML
Kompatibilität	JAVA	-	OCAML

Vergleich von J# und F#

Der Vergleich zeigt, dass sich J# und C# einfach zu ähnlich sind, als dass es einen wirklichen Gewinn bringen wurde. Wer Java programmieren will, der macht das mit Java und nicht mit J#. Zumal man mit Eclipse eine weitaus bessere Entwicklungsumgebung hat. F# hat hingegen nichts mit C# zu tun. Die Sprache basiert nicht auf C sonder auf ML (Meta Language). Auch die Art der Programmierung ist anders, nämlich funktional. Microsoft hat jedoch mit F# ein paar Zugeständnisse gemacht. F# bezeichnet sich selber als "Multi Paradigmen" Programmiersprache, im Gegensatz zu reinen funktionalen Programmiersprachen wie Haskell. Man kann z.B. mit F# objektorientierte Klassenbibliotheken definieren, die von anderen .NET Programmen aufgerufen werden können.

Fazit

F# kann nicht mir J# verglichen werden, auch wenn es viele Ähnlichkeiten aufweist. Nicht in der Art der Syntax, sondern in der Art wie F# marketingtechnisch platziert wird. Ich vermute ganz stark, dass F# einen großen Einfluss auf die Weiterentwicklung von C# und .NET haben wird. F# hat dazu beigetragen, dass C# 2.0 Generics erhalten hat. Für C# 3.0 und LINQ wurden weitere Konzepte der funktionalen Welt in die objektorientierte Welt übertragen: Typinferenz, Lambda Ausdrücke und das sehr esoterische Konzept der Monadentheorie. Ich spekuliere dass C# 5.0, nachdem C# 4.0 Features aus der dynamischen Welt bekommen hat, wieder Konzepte aus der funktionalen Welt adaptieren wird. Meine Wunschfeatures für C# 5.0 sind: Pattern Matching, erweiterte Typinferenz, und Metaprogrammierung.

Ich glaube, dass man folgendes plakativ von F# sagen kann (andere funktionale Sprachen eingeschlossen):

Dank F# gibt es Generics. Dank F# gibt es Lambda Ausdrücke. Dank F# gibt es LINQ.

Danke F#!

Ausblick

Ich habe vor ein paar grundlegende Blogeinträge zu F# zu schreiben. Im nächsten Blog Eintrag wird es darum gehen, warum man eigentlich F# verwenden sollte.

Silverlight 3

2009-03-18T15:11:00.001Z

WOW!

Bereits vor der eigentlichen Ankündigung bei der Keynote auf der Mix09, ist das Silverlight 3 SDK freigegeben worden. Ob es jetzt offiziell ist, weiß ich nicht - auf jeden Fall kann man es jetzt schon downloaden ;-))

Als WPF Entwickler war ich eher enttäuscht von Silverlight 2. Ein intuitives programmieren war nicht möglich. Eigentlich war es nur ein Krampf. Also habe ich beschlossen "Silverlight" erst mal "silverNight" sein zu lassen. Bis ... ja bis heute.

Auf die Schnell konnte ich folgende interessanten, lang erwarteten und teilweise überraschenden Neuerungen feststellen.

ObservableCollection<T>

Wie bereits aus WPF bekannt, implementiert diese Collection das INotifyCollectionChanged Interface. Damit können Controls feststellen, ob sich etwas an dieser Collections geändert hat, also Items hinzugefügt oder gelöscht wurden, so dass man die UI aktuallisieren kann. Siehe ItemsControl und ListBox

ICollectionView

Eng mit der ObservableCollection sind die sog. CollectionViews verbunden. In WPF gibt es diverse View Implementiereungen, ItemsCollectionView, EnumerationCollectionView, ListCollectionView, BindingListCollectionView. Diese gibt es aber nicht in Silverlight 3.

PagedCollectionView

Interessanterweise gibt es aber die PagedCollectionView; die es aber nicht in WPF gibt...

Nachwievor bewegen sich WPF und Silverlight immer noch stark auseinander. Leider.

Animationen

Für Animationen gibt es jetzt "Ease" Funktionen. Diese interpolieren eine Funktion die z.B. eine Beschleunigung simuliert. So kann man z.B. auch einen Ball springen lassen.

In WPF kann man solche Effekte über "KeySplines" erzeugen, aber auch diese gibt es nicht in Silverlight.

Weitere Neuerungen werden noch gepostet. Stay tuned.

So jetzt schnell nach Hause, damit ich mir die Keynote live gestreamt angucken kann!

WPF Window als Vollbild

2009-01-28T11:13:00.002Z

Ein WPF Fenster kann auch im Vollbildmodus angezeigt werden und somit den gesamten Bildschirmplatz einnehmen ohne die Windowsstartleiste

Wie funktioniert das?

Nun, es ist einfacher als man denkt. Dafür braucht man keine nativen Windows APIs aufzurufen.

Folgender XAML Code zeigt wie es geht:

<Window x:Class="WpfApplication1.Window1"

xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"

xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"

Title="Window1"

WindowStyle="None"

WindowState="Maximized"

WindowStartupLocation="CenterScreen">

</Grid>

</Window>

Zunächst wir der WindowState mit Maximized angegeben. Das bewirkt natürlich dass das Fenster den gesamten Bildschirm ausfüllt.

Den ganzen Bildschirm? Nein, denn unten (oder oben) [oder auch an den Seiten] befindet sich die Windows Taskbar.

Wird nun der WindowStyle wird auf None gesetzt, hat das Fenster keinen Rahmen, also auch keine Titelleiste und Controlbar.

Allerdings verschwindet nun auch die Taskbar und das Fenster füllt tatsächlich den gesamten Screen aus.

Nun kann z.B. eine Photoshow starten.

Problematisch wird es, wenn der Anwender versucht das Fenster zu schließen, denn es fehlt ja die Titelleiste mit dem Schließen bzw. Minimieren Button. Man sollte daher noch auf Events der Tasten ESC oder F11 reagieren. Diese werden standardmäßig in Vollbild Applikationen verwendet, um in den normalen Fenstermodus zurückzukehren.

public
partial
class
Window1 : Window

{

public Window1()

{

InitializeComponent();

this.KeyDown = RootKey;

}

void RootKey(object sender, KeyEventArgs e)

{

if ((e.Key == Key.Escape) (e.Key == Key.F11))

{

if (this.WindowStyle == WindowStyle.None)

{

this.WindowStyle = WindowStyle.ThreeDBorderWindow;

this.WindowState = WindowState.Normal;

}

else

{

this.WindowStyle = WindowStyle.None;

this.WindowState = WindowState.Maximized;

}

e.Handled = true;

}

Ob dieses Feature beabsichtigt ist; weiß ich nicht. Ob dieses Feature jede Anwendung benötigt? Eher nicht.

Wer allerdings eine Vollbild Anwendung entwicklen will, der kann auch das mit WPF tun, und zwar mit relativ wenig Aufwand.

PDC08: new XAML features

2008-10-08T11:08:00.002+01:00

XAML ist DIE deklarative Programmiersprache für .NET.

Sie findet hauptsächlich Anwendung in WPF, aber auch in WF und WCF

Auf der PDC wird sich eine Session rund um XAML drehen. Es wird gezeigt wie eine Anwendung komplett deklarativ in XAML geschrieben werden kann.

XAML wird außerdem mit XOML aus der Workflow Foundation vereinigt. Man darf gespannt sein auf welche Anwendungsbereiche XAML ausgeweitet werden wird.

Neue XAML Features werden sein:
- support für generics
- object references
- non default constructors

cu @ PDC
Benjamin

C# 4.0: dynamic

2008-10-08T09:31:00.003+01:00

C# wird dynamisch!

Das erste publik gemachte Feature von C# 4.0 sind dynamic lookups. Diese werden durch das neue Schlüsselwort - dynamic - ermöglicht.

Dynamic lookups ermöglichen das Auflösen von Namen zur Laufzeit und nicht zur Compilezeit. Das bedeutet, dass dies ein neues Runtime Feature ist, denn ein Sprachfeature von C#. Alle .NET Sprachen können also diesen dynamic lookup verwenden. VB.NET konnte dieses Szenario bereits umsetzen - besser bekannt als "Late Binding" - , musste jedoch deafür auf eigene Methoden aus der Microsoft.VisualBasic.dll zurückgreifen. (Daher musste man bisher immer diese DLL deployen, wenn man .NET in VB programmiert hat).

Dynamic Lookups sind in der DLR (Dynamic Language Runtime) implementiert und für dynamische Sprachen unerlässlich.

Das folgende Beispiel ist den Slides der Keynote von Anders Hejsberg auf der JAOO entnommen

Olso und D#

2008-09-10T08:45:00.002+01:00

Während die PDC immer näher rückt, werden die ersten heiß erwarteten Neuerungen bekannt. Unteranderem kommen immer mehr Details zum Vorschein, zu der langerwarteten Plattform Olso, die Teil des .NET Framework 4.0 sein wird.

Don Box ist einer der Architekten von Oslo und gibt in seinem Blog kleine versteckte Hinweise. Heute wies er auf einen interessanten Artikel hin, der weitere Geheimnisse zu Olso enthüllt.

Nach LINQ wird dieses Jahr ein weiterer Hammer vorgestellt werden:
Textuelle Domain Specific Languages (DSL)

Microsoft hat bereits ein DSL Toolkit mit dem man graphische DSL erstellen kann. Diese können dann über einen Designer in VisualStudio verwendet werden. Das Neuartige and denOslo DSL ist, dass sie wie eine eigene Programmiersprache funktionieren; also textuell. Diese TDSL basieren auf dem Microsoft Research Projekt TLA+ (T-emporalen L-ogik der A-ktionen)

Übrigens der Codename für diese TDSL ist "D".
Vielleicht bekommen wir nach C# nun ein D# !?

C.U. at PDC
Benjamin

PDC2008 I'm comming

2008-05-29T06:32:00.002+01:00

Bei der letzten PDC habe ich mir noch alle Sessions online angesehen.

Jetzt bin ich LIVE dabei!

Themen werden sein:

- The Live Developer platform, including the MESH.
- Cloud Computing" from computation, to storage and much more!
- Visual Studio 10" and .NET Framework 4.0
- ASP.NET Futures including v.next of MVC, Ajax and Dynamic data
- Silverlight Futures, including Silverlight for business applications
- And much, much more.

StackPanel Items in umgekehrter Reihenfolge anzeigen

2008-05-08T16:27:00.001+01:00

Das StackPanel in WPF kann Controls untereinander anordnen.

Mit der Eigenschaft Orientation=Horizontal ist es möglich auch die Elemente von Links nach Rechts anzuordnen.

Es gibt aber keine Eigenschaft StackItemsFrom="Top|Bottom".

Natürlich kann man ein eigenes StackPanel implementieren, das dies kann. Es geht aber auch einfacher.

Am Anfang war das ItemsControl

Wir benötigen zunächst ein ItemsControl. Ein ItemsControl kann beliebige Objekte, also auch Double, Boolean, Person etc., aufnehmen. Ein Panel hingegen nur Controls.

Das ItemControl benötigt jedoch ein Panel um die Objekte darstellen zu können. Standardmäßig ist dies ein StackPanel.

Über die Eigenschaft ItemsPanel können wir ein ItemsPanelTemplate definieren, und ein anderes von Panel abgeleiteten "Panel" angeben, in das nun die Items angeordnet werden.

Wie die Objekte aussehen bestimmt ein DataTemplate. Für jedes Objekt generiert das ItemsControl einen Container (ContentPresenter, für ListBox -> ListBoxItem). Da man auf diesen Container nicht direkt zugreifen kann, definiert das ItemsControl eine Property um den Style für den "ItemContainer" festlegen zu können.

Verkehrte Welt

Um nun die Elemente von unten nach oben statt von oben nach unten anordnen zu können, wie es das StackPanel macht, benötigen wir ein anderes Panel. Ein DockPanel ist geeignet, da es mehr als eine Möglichkeit gibt, Elemente in ihm anzuordnen. (Top,Left,Right,Bottom).

Nun müssen wir noch im ItemContainerStyle festlegen, dass die Elemente jeweils von Unten angeordnet werden sollen.

<ItemsControl.ItemsPanel>

</ItemsPanelTemplate>

</ItemsControl.ItemsPanel>

<ItemsControl.ItemContainerStyle>

<Style>

</Style>

</ItemsControl.ItemContainerStyle>

</ItemsControl>

Et Voila

AttachedProperties richtig initialisieren

2008-05-08T12:04:00.001+01:00

Manchmal ist es angebracht, nachdem sich ein Objekt bei einem AttachedProperty registriert hat, einige Initialisierungen durchzuführen. Hierbei kann in der Set Methode, nach dem Setzen des AttachedProperty, z.B. eine Initialisierungsmethode aufgerufen werden.

public
static
void SetAttachedProperty(DependencyObject obj, int value)

{

obj.SetValue(AttachedProperty, value);

InitializeProperty();

}

Die Set-Methode macht nichts Weiteres, als bei dem übergebenen DependencyObjekt SetValue aufzurufen. Der eigentliche Wert der AttachedProperty wird also wie eine ganz normale DependencyProperty gesetzt. Stellen Sie sich einfach vor, eine DependencyProperty ist nichts anderes als ein Schlüssel der zusammen mit einem Wert in einem Dictionary gespeichert wird. Jedes DependencyObject hat so ein Dictionary. Die Werte können aber auch von anderen Objekten abgefragt und gesetzt werden.

Um eine AttachedProperty zu setzen, reicht es tatsächlich lediglich die DependencyProperty am eigenen Objekt zu setzen und nicht am Containerobjekt durch Set[Property]! Das bedeutet aber auch, dass die Initialisierungsmethode nicht mehr aufgerufen wird, da die AttachedProperty über einen anderen Weg gesetzt wird. Nun kann man es natürlich zur Konvention machen in dem in einem API vorschreibt, dass AttachedProperties immer über Set[Property] gesetzt werden müssen. So ist der XAMLReader drauf angewiesen, dass wenn er eine AttachedProperty im Markup erkennt, auch eine entsprechende Set-Methode verfügbar ist, die er aufrufen kann.

Trotzdem ist es besser eine Initialisierung anders durchzuführen. Wie? Über einen Callbackmechanismus. Jede DependencyProperty verfügt über Metadaten die es erlauben, Code bzw. Callbacks für Validierungen, Änderungen etc. zu hinterlegen. Ändert sich z.B. der Wert einer DependencyProperty, so wird der Callback aufgerufen und die Initialisierung kann durchgeführt werden. Dieser Mechanismus funktioniert unabhängig davon wie eine DependencyProperty, gesetzt wurde.

public
static
readonly
DependencyProperty PropertyWithCallback;

//Definition der Metadaten mit Callback

PropertyMetadata metadata = new
PropertyMetadata();

metadata.PropertyChangedCallback += OnPropertyWithCallbackChanged;

//Registrierung der DependencyProperty

PropertyWithCallback = DependencyProperty.RegisterAttached("PropertyWithCallback",

typeof(int), typeof(Window1), metadata);

//Der Callback ruft die eigentliche Initializierungsmethode auf

private
static
void OnPropertyWithCallbackChanged(DependencyObject obj, DependencyPropertyChangedEventArgs value)

{

InitializeProperty();

}

Eigene Linien in Grid Panel zeichnen

2008-05-07T08:36:00.002+01:00

Das Grid ist das Mächtigste und am Häufigsten gebrauchte Panel in WPF.

Mit der Eigenschaft "ShowGridLines" lassen sich Hilfslinien anzeigen.

Diese Linien dienen nur als Hilfestellung für den Entwickler, der so die Position der Spalten und Reihen erkennen kann.

Leider kann man nicht selber bestimmen wie diese Linien aussehen. Oder etwas doch?

Was passiert eigentlich im Grid wenn ShowGridLines=True gesetzt wird?

WPF-Controls können sich selbst zeichnen, in dem sie die OnRender Methode überschreiben. Wie dies auch bei OnPaint in WinForms der Fall ist.

Doch beim Grid wird davon nicht Gebrauch gemacht um die Linien zu zeichnen! Stattdessen wird zu den logischen UI-Elementen in dem Panel ein zusätzliches visuelles Element der "GridLinesRenderer" hinzugefügt. Dies geschieht nicht per ControlTemplate. (Templates ändern ebenfalls das Aussehen also den VisualTree), sonder programmatisch durch den Aufruf von AddVisualChild(visual) in der Basisklasse.

Der GridLinesRenderer ist von DrawingVisual abgeleitet. UIElement und DrawingVisual haben also den Selben Vorfahr "Visual". DrawingVisuals sind jedoch wesentlichen performanter als UIElements, da sie direkt auf den "Bildschrim" (WPF-Subsystem) zeichnen.

Der VisualTree im XamlPad zeigt, dass neben dem logischen Child – einem Button - noch ein visuelles Element - der GridLinesRenderer - in der Hierarchie zu finden ist.

Möglichkeit 1: Einen eigenen GridLinesRenderer schreiben

Meine erste Idee war es einen eigenen GridLinesRenderer zu schreiben. Ganz nach dem Vorbild des in dem Grid zu findenden Renderer.

Das Problem ist, dass es nicht möglich ist den Renderer in den VisuallTree des Grid einzufügen. Die Methode die dieses möglich machen würde – AddVisualChild – ist nämlich protected.

Ein eigenes Grid zu erstellen, nur um die GridLinien zeichnen zu können war mir dann aber zu aufwändig.

Es muss einen anderen Weg geben.

Möglichkeit 2: Einen GridLinesAdorner schreiben

Wenn es keine Möglichkeit gibt ein UIElement von Innen zu verändern ohne ein eigenes Control abzuleiten, so muss man es eben von Außen probieren. Das machen sog. Adorner.

Adorner "verzieren" ein UIElement. Wie, das bestimmt der Adorner. Wichtig ist, dass ein Adorner immer über einem UIElement gezeichnet wird. D.h. der Adorner verdeckt darunter liegende Zeichnungen.

Public
Class GridLinesAdorner

Inherits Adorner

Private Grid As System.Windows.Controls.Grid

'Übergabe des zu verzierenden Elements (hier Grid)

Sub
New(ByVal grid As System.Windows.Controls.Grid)

MyBase.New(grid)

Me.Grid = grid

End
Sub

Private _pen As Pen

'Stift um die Linien zeichnen zu können

Public
Property Pen() As Pen

Get

Return _pen

End
Get

Set(ByVal value As Pen)

_pen = value

End
Set

End
Property

'Zeichnen der Linien

Protected
Overrides
Sub OnRender(ByVal dc As System.Windows.Media.DrawingContext)

If Pen Is
Nothing
Then
Exit
Sub

If Grid.ColumnDefinitions.Count > 0 Then

Dim x As
Double

For i As
Integer = 1 To Grid.ColumnDefinitions.Count - 1

x = Grid.ColumnDefinitions(i).Offset

dc.DrawLine(Pen, New Point(x, 0), New Point(x, Grid.ActualHeight))

End
If

If grid.RowDefinitions.Count > 0 Then

Dim y As
Double

For i As
Integer = 1 To Grid.RowDefinitions.Count - 1

y = Grid.RowDefinitions(i).Offset

dc.DrawLine(Pen, New Point(0, y), New Point(Grid.ActualWidth, y))

End
If

End
Sub

End
Class

Die Methode OnRender führt nun das Zeichnen der Gridlinien durch. Über die Row- und ColumnDefinitions des Grid, kann der Offset der einzelnen Spalten vom Grid abgerufen werden. Diese dienen uns als Koordination um an diesen Stellen die entsprechenden Linien zu zeichnen.

Anwenden des Adorners

Um den Adorner zum Einsatz zu bringen, müssen wir nun noch die Code-Behind Datei anpassen. Leider ist es nicht möglich den Adorner in XAML direkt anzuwenden. (Die Klasse AdornerDecorator ist nur dafür da einen Layer für ein zu verzierendes Element bereitzustellen, worauf ein Adorner angewendet werden kann; aber nicht für den Adorner selbst.)

Class Window1

Private
Sub Window1_Loaded(ByVal sender As
Object, ByVal e As System.Windows.RoutedEventArgs) Handles
Me.Loaded

'Layer für das Element holen in dem der Adorner gezeichnet wird

Dim layer As AdornerLayer = AdornerLayer.GetAdornerLayer(Me.Grid)

'Adorner mit Stift erstellen

Dim adorner As
New GridLinesAdorner(Grid)

adorner.Pen = New Pen(Brushes.Black, 2)

'Adorner dem Layer hinzufügen

layer.Add(adorner)

End
Sub

End
Class

Das Ergebnis

Wer noch einen Rahmen um das Grid herum haben möchte, der brauch nur noch das Grid in ein Border zu packen.

Achtung: Wie man sieht wird der Adorner über das Grid gezeichnet. Daher sind die Ränder der im Grid befindlichen Buttons nicht ganz zu sehen.

Hier muss dann noch ein entsprechendes Margin auf die Buttons angewendet werden um den richtigen Abstand zu den Gridinnenseiten zu ermöglichen.

WPF goes Transitions

2008-04-29T21:02:00.002+01:00

Effekte a la PowerPoint? Mit WPF kein Problem!?

WPF bietet zwar Animationsunterstützungen, doch diese müssen mühsam programmiert werden.

Nun gibt es ein Framework das Übergangseffekte für WPF bereitsstellt.
z.B. Wipe, Fade, oder RotatingCube. Auch aufwendige 3D Animation sind frei verfügbar.

Entwickelt hat dies Jaraed Bienz.
Download auf CodePlex: Transitionals

Wer jetzt vielleicht sagt: "He, das habe ich schonmal gesehen!"
der hat vollkommen recht. Auf der letzten Basta habe ich einen Vortrag über CAB gehalten und auch Acropolis vorgestellt. Für mich hatte Acropolis keine Zukunfstaussichten (Wurde ja auch eingestampft). Jedoch einige Bestandteile hatten Potential in WPF intigriert zu werden. U.a. auch das Transitionframework.

Zwar ist das Transitionframework (noch) kein Teil von WPF. Aber dennoch sehr nützlich, zumal frei zugänglich und erweiterbar.

Basta! 2008 Spring Edition

2007-12-10T17:24:00.000Z

Schon zum 2. Mal werde ich auf der BASTA! sprechen.

Meine Session(s)

Reflection in Action

Reflection gehört zu den coolesten und nützlichsten Features von .NET. In dieser Session schauen wir uns die bekannten und unbekannten Möglichkeiten von Reflection an. U.a. Wie performant ist Reflection und wie kann man die Performance optimieren? Wie generiert man dynamisch IL Code und kann ihn wieder auslesen!? Und vieles vieles mehr.

Allein dafür lohnt es sich auf die BASTA! zukommen.

Benny

PDC2008 announced!

2007-12-07T09:39:00.000Z

Nachdem die PDC2007 ausgefallen ist, weil "zu wenig Neues" und die TechEd2007 Europe tatsächlich wenig Neues zu bieten hatte, findet sie nun statt:

die PDC2008 in Los Angeles!

Link

Vermutliche Themen:
- .NET Framework 4.0
- Volta (MSIL Recompiler)
- Software + Services
- WPF Composite Smart Clients
- (hoffentlich neue (WPF Controls bzw. Features))
- Silverlight 2.0 und DLR

Urlaub ist schon geplant!

Benny

WPF Composite Clients formally known as Acropolis

2007-10-30T07:39:00.000Z

Das war es also mit "Acropolis". Dem Produkt das eigentlich CAB (Composite UI Application Block) ersetzen sollte...

Hier die offizielle Bekanntmachung:
Acropolis Team Blog

Die Erkenntnisse aus dem Acropolis Projekt werden zerstückelt und fließen in die .NET Klassenbibliothek ein (Version 4.0?). Dies Vermutung habe ich bereits auf der BASTA! 2007 in Mainz geäußert, wo ich einen Vortrag über CAB gehalten habe und einen Ausblick auf Acropolis gezeigt habe. Ein Artikel für das dotnet Magazin war bereits in Arbeit. Aber eine innere Stimme hat mich zurückgehalten weiter zu machen. Jetzt weiß ich warum!

Von Seiten der CAB-Community hagelte es eine Menge Kritik an Acropolis. Der Ärger bestand darin dass CAB und die Smart Client Software Factory nicht mehr weiterentwickelt werden. Stattdessen wurde das ehrgeizige Projekt Acropolis hochgezogen, dass viel wollte aber nichts konnte. Das größte Problem war eine nicht existierende Roadmap für das Produkt.

Hier ein Kommentar dazu aus der CAB Comunity.

Requiem for Acropolis; Fanfare for CAB +

Aber es gibt schon wieder ein Neues Projekt: WPF Composite Clients

Diesmal wieder unter der Leitung der Patterns & Practices Group. Hier fließt die ganze Erfahrung aus CAB mit ein. Acropolis ist (war) nähmlich ein Projekt der UIFX Teams, das für ASP.NET und WPF zuständig ist.

Glen Block bescheibt in seinem Blog das neue Projekt.
Glenn Block

WPF Composite Client ist keine neue Version von CAB. Es wird eine neue Library und Guidance geben. Zielplattform ist WPF. Der Grund für den Aufbau einer neuen Klassenbibliothek besteht darin, dass CAB nicht für WPF designt wurde. WPF bringt eigene Konzepte wie Commands und RoutedEvents mit sich, die es in WinForms nicht gibt und somit auch nicht in CAB unterstützt werden.

WPF bietet außerdem eine komplette andere "experience". Es wird daher keinen Migrationspfad von WinForms geben. (So wie dies noch in Acropolis vorgesehen war).

Wie herausklang wird es weiter Verbesserungen an WinForms geben! WinForms geht also noch nicht in Rente.

Ich lass erstmal die Korken knallen, dass wir das Thema Acropolis hinter uns lassen können! Ich habe schon befürchtet, dass wir uns ernsthaft mit dem Produkt auseinandersetzen müssen!

CSV Dateien verarbeiten mit LINQ

2007-10-10T12:25:00.000+01:00

Mein erster (langer) Artikel in der dotnetpro (http://www.dotnetpro.de/) ist erschienen!

Ich zeige, dass man mit LINQ nicht nur Datenbanken ansprechen kann, sondern ganz simple auch CSV Dateien einlesen, filtern und ausgeben kann. Mit LINQ und C# 3.0 ist das eine Sache von 3 Zeilen Code.

Auf die Idee bin ich durch den Contest der dotnetpro gekommen. Die Aufgabenstellung war CSV Daten zu verarbeiten. Es war abzusehen, dass die jeder mit einer Datenbank angehen würde. Der eine verwendet SQLServer, der andere MySQL. Besonders beliebt bei dem Contest war aber SQLLight.

Und der der Gewinner ist....

Gewonnen habe ich dann, mit meiner Lösung nicht. Und das obwohl ich 25% schneller war als die Siegerlösung!!!
(Ja Mama! Es waren wieder einmal die Flüchtigkeitsfehler)

Neulich auf der BASTA

2007-09-22T16:14:00.000+01:00

Hallo,

da bin ich also Zurück vom Abenteuer BASTA. Ich kann nur sagen ich hab's überlebt!

Die Keynote sollte eigentlich Dirk Primps halten. Das hat er aber irgendwie verpennt!
Er wurde natürlich von den anden Speakern ständig daran aufgezogen.

Das Essen beim Speakerdinner war nicht nach dem Geschmack der Meisten. So gab es z.B. Schafskäse an Raffaello. Das Essen auf der Konferenz war tiefkühlfraß und schlimmer als bei McDonalds. Kein Wunder, dass einige Teilnehmer und auch Speaker so ihre Probleme hatten. Holger S. hat seine Session mit Durchfall gehalten, Neno stand aber bereit um für Ihn einzuspringen.

Christian Groß hat sich bei seinem Workshop, das Handy eines Teilnehmers geschnappt und sich damit auf den Boden geworfen! Er wollte das Thema Security etwas verdeutlichen.

Der Oberhammer war Oliver Sturm. Hat er doch die 10 coolsten Features in C# 3.0 gezeigt. Er hat sich extra einen Timer programmiert und die Features auf die Sekunde vorgeführt. Man hat er die Leute weggeblasen. Er von Dingen geredet die die Leute noch in C# 5.0 kappieren werden.

Feucht fröhlich ging es beim Abschlussessen weiter:
Jörg N.: "Jetzt geht schon wieder die Diskussion los, was besser ist C# oder VB
Jörg N.: "Ich bin einfach nur müde"
Benny G.: "VB ist eine Lebenseinstellung"
Daniel F.: "VB ist eine Krankheit"
Oliver S.: "VB ist eine Lebenseinstellung -
so wie Arbeitslosigkeit!"

In diesem Sinne, bis zur nächsten BASTA!

Benjamin

Der Name "InitializeComponent" wurde nicht deklariert

2007-09-08T20:08:00.000+01:00

Hallo WPF Freunde!

In letzter Zeit verwende ich immer mehr WPF in meinen Anwendungen. Ganz auf WinForms möchte ich aber nicht versichten. Aus Gewohnheit nehme ich für einen neues VisualStudio Projekt die Projektvorlage "WinForms Anwendung". Wenn ich nun versuche ein WPF-UserControl zu meinem Projekt hinzufüge erscheint beim Kompilieren diese Fehlermeldung:

Der Name "InitializeComponent" wurde nicht deklariert

Mir kamen sofort einige Fragen in den Sinn:
-Habe ich .NET 3.0 richtig installiert?
- Habe ich die .NET 3.0 Extensions für VisualStuido richtig installiert?
- Ist meine XAML Datei in Ordnung?
- Macht ExpressionBlend die Probleme (damit designe ich die UserControls)?

Die Lösung ist dann doch relativ einfach.
Man muss die Projektdatei *.proj öffnen und dem BuildSystem von VisualStuido MSBuild mitteilen wie es XAML und Code-Behind Dateien zu kompilieren hat.

Diese Zeile muss man einfügen:

<import project="$(MSBuildBinPath)\Microsoft.WinFX.targets">

Klar, dass die normale .NET 2.0 WinForms Anwendung Projektvorlage noch nichts von XAML und WPF gehört hat und dementsprechend die Dateien nicht richtig kompilieren kann.

Benjamin Gopp

LINQ wird missverstanden!

2007-08-05T09:18:00.000+01:00

In der Ausgabe 9 des dotnet magazins ( http://www.dotnet-magazin.de ) sind in der OpenStage Kolumne meine Gedanken zu LINQ abgedruckt. Nachdem der Artikel nun erschienen wird er auch hier "abgeblogged".

Mittlerweile habe ich schon dutzende Artikel und Vorträge zu LINQ gehört. Und immer wieder sehe am Inhalt der Vorträge und den Reaktionen, dass LINQ missverstanden wird. Auch die Innovatoren von LINQ tragen nicht gerade zur Klarheit bei. Ein typisches (schlechtes) LINQ-Beispiel ist:
From c in Customer Where c.City == “London“ Select c
Dieses Beispiel suggeriert, dass man es hier mit SQL zu tun hat. Zugegeben etwas verdrehtes SQL, das From steht vorne und das Select hinten, aber es sieht nach SQL aus. Die Assoziation die dabei unweigerlich beim Programmierer entsteht ist Folgende: Linq … SQL … Datenbank; Ah! Linq ist für Datenbanken bestimmt. Die ganze Power von LINQ verpufft in diesem Moment, wo LINQ mit SQL gleich gesetzt wird und auf die Verwendung von Datenbanken reduziert wird.
Liege ich mit meiner Einschätzung so falsch? Ein Blick in das LINQ MSDN-Forum zeigt, dass über 90% der Fragen auf die Verwendung von LINQ in Verbindung mit Datenbanken abzielen. Da wird von LINQ sogar als O/R Mapper gesprochen.
Auch die LINQ Queryoperatoren tragen nicht gerade dazu bei, dass man sich von SQL unterscheiden will. From, Select, Where - diese kennen wir alle von SQL. Was LINQ gerade auszeichnet, ist aber dass man alle Datenquellen befragen kann, also auch Objekte und XML etc.. Was vorher nur auf Datenbanken beschränkt gewesen ist, ist nun für andere Datenquellen möglich. Das ist das Revolutionäre an LINQ! Ein einheitliches Konzept um Daten abzufragen!
Natürlich muss auch ein einheitliches API für LINQ gefunden werden. Es kann schlecht sein, dass man um Datenbanken abzufragen eine andere Syntax verwenden muss, als für XML oder Objekte. Das hatten wir nämlich bisher: SQL für Datenbanken, XPath für XML und diverse Methoden für Arrays. Damit soll nun Schluss sein. Warum gerade aber LINQ so nah an SQL angelehnt ist, kann ich nicht verstehen. Vielleicht will man damit LINQ schneller etablieren. Langfristig gesehen wird man sich damit aber Probleme einhandeln. Wir können erwarten, dass mit der Zeit LINQ Implementationen für exotischere Datenquellen, auftauchen werden. Dann mag eine SQLnahe Syntax nicht mehr passend sein! Und dann sind wir bei dem Punkt angelangt, was LINQ eigentlich vermeiden wollte, nämlich fester Bestandteil einer Programmiersprache zu werden. Denn Programmiersprachen leben länger als APIs.

My Extensions in VS2008

2007-07-28T20:53:00.000+01:00

Nach einem Tag downloaden und Installation, habe ich nun endlich die Beta2 von Visual Studio 2008 "Orcas" auf meinem Rechner.

Aufgefallen ist mir der neue Projekttab "My Extensions"

Sollte es damit einfacher möglich sein neue Erweiterungen für den My Namespace zu erstellen?

Der Link "Learn more about customizung the My Namespace" war leider tot. Auch nachdem ich die 2Gig große VS2008MSDN runtergeladen und installiert hatte.

Gefunden habe ich dann doch noch, wonach ich gesucht hatte. Und zwar die Quelldatei für die WPF My Extensions, die bereits in Orcas auszuwählen sind. Diese befindet sich unter dem Ordner "My Project" in dem Ordner "MyExtensions". Dort wird man dann auch in Zukunft eigene Extensions für den My Namespace ablegen können.

Bleibt nach wie vor die Frage: Woher weiß VisualStudio, dass eine "My Extension" vorhanden ist? Ich habe weder eine Assembly noch ein Item-Template gefunden, dass die Vorlage für die "WPF My Extension" liefert. (Eine entsprechende Frage wie man denn diese My Extensions verwendet habe ich gleich nach der Entdeckung in das MSDN Forum gestellt. Mal gucken ob in nächster Zeit eine Anwort darauf zu finden ist.)

Demnächst erscheint ein Artikel von mir im dotnet.magazin über das Erstellen eines eigenen My Namespaces. Der My.Data Namespace bietet einfachen Zugriff auf eine im Vorhandene Datenbank. Der Artikel ist deswegen nur noch nicht fertig, weil das Deployment von My Extensions Probleme macht. Die Erweiterungen bestehen nämlich aus generiertem Code, der von den Projekteinstellungen abhängt, und kann deswegen nicht als Assembly verteilt werden. Es bleibt also nur noch ein Item-Template übrig für ein simples Deployment. Wenn man eine Vollintegration haben will, muss man wohl oder übel ein eigenes Add-In für Visual Studio schreiben. Das finde ich aber zu Aufwendig.

Auf der Basta 2007 Spring hatt ich mit Jay Schmelzer (Principal Program Manager Visual Basic) meine My.Data Erweiterung vorgestellt und mit ihm darüber gesprochen, wie man eigene My Erweiterungen in Visual Studio integrieren kann. Er versprach dies für Orcas mit einzuplanen.

Schade Jay, das war eigentlich nicht das, was ich mir vorgestellt hatte!

#If _MyType <> "Empty" Then
Namespace My
'''

''' Module used to define the properties that are available in the My Namespace for WPF
'''

'''
_
Module MyWpfExtension
Private m_Computer As New ThreadSafeObjectProvider(Of Global.Microsoft.VisualBasic.Devices.Computer)
Private m_User As New ThreadSafeObjectProvider(Of Global.Microsoft.VisualBasic.ApplicationServices.User)
Private m_Windows As New ThreadSafeObjectProvider(Of MyWindows)
Private m_Log As New ThreadSafeObjectProvider(Of Global.Microsoft.VisualBasic.Logging.Log)
'''

''' Returns the application object for the running application
'''

Friend ReadOnly Property Application() As Global.System.Windows.Application
Get
Return Global.System.Windows.Application.Current
End Get
End Property
'''

''' Returns information about the host computer.
'''

Friend ReadOnly Property Computer() As Global.Microsoft.VisualBasic.Devices.Computer
Get
Return m_Computer.GetInstance()
End Get
End Property
'''

''' Returns information for the current user. If you wish to run the application with the current
''' Windows user credentials, call My.User.InitializeWithWindowsUser().
'''

Friend ReadOnly Property User() As Global.Microsoft.VisualBasic.ApplicationServices.User
Get
Return m_User.GetInstance()
End Get
End Property
'''

''' Returns the application log. The listeners can be configured by the application's configuration file.
'''

Friend ReadOnly Property Log() As Global.Microsoft.VisualBasic.Logging.Log
Get
Return m_Log.GetInstance()
End Get
End Property
'''

''' Returns the collection of Windows defined in the project.
'''

Friend ReadOnly Property Windows() As MyWindows
_
Get
Return m_Windows.GetInstance()
End Get
End Property
_
_
Friend NotInheritable Class MyWindows
_
Private Shared Function Create__Instance__(Of T As {New, Global.System.Windows.Window})(ByVal Instance As T) As T
If Instance Is Nothing Then
If m_WindowBeingCreated IsNot Nothing Then
If m_WindowBeingCreated.ContainsKey(GetType(T)) = True Then
Throw New Global.System.InvalidOperationException("The window cannot be accessed via My.Windows from the Window constructor.")
End If
Else
m_WindowBeingCreated = New Global.System.Collections.Hashtable()
End If
m_WindowBeingCreated.Add(GetType(T), Nothing)
Return New T()
m_WindowBeingCreated.Remove(GetType(T))
Else
Return Instance
End If
End Function
_
Private Sub Dispose__Instance__(Of T As Global.System.Windows.Window)(ByRef instance As T)
instance = Nothing
End Sub
_
_
Public Sub New()
MyBase.New()
End Sub
Private Shared m_WindowBeingCreated As Global.System.Collections.Hashtable
Public Overrides Function Equals(ByVal o As Object) As Boolean
Return MyBase.Equals(o)
End Function
Public Overrides Function GetHashCode() As Integer
Return MyBase.GetHashCode
End Function
_
Friend Overloads Function [GetType]() As Global.System.Type
Return GetType(MyWindows)
End Function
Public Overrides Function ToString() As String
Return MyBase.ToString
End Function
End Class
End Module
End Namespace
#End If

Wie kann ich Controls in einer Form zentrieren?

2007-07-16T12:47:00.000+01:00

Ich habe eine sehr einfache Methode herausgefunden um ein beliebiges Steuerelement in einer Form zu zentrieren; also genau mittig anzuzeigen. Wenn die Form verschoben wird, soll natürlich auch die Position des Controls wieder an die neue Mitte verschoben werden.

Meine Lösung erfordert keinen Code!

Man nehme ein TableLayoutPanel und stellt seine Dock Eigenschaft auf Dock.Fill. Nun füllt das Panel die ganze Form aus. Dann reduziert man das Panel auf genau 1 Zelle, d.h. RowCount und ColumnCount = 1. Auchtung eine Zelle kann immer nur 1 Control beinhalten. Wer daher mehere Elemente mittig anzeigen lassen will muss ein weiteres Panel verwenden in das er diese Elemente einfügt. Das Control wird nun auf Anchor = Anchor.None gesetzt. Siehe da das Control befindet sich nun immer in der Mitte!

Achtung! .NET 3.5 Beta1 und .NET 3.5 June CTP inkompatibel!

2007-07-13T13:55:00.000+01:00

Achtung bei dem Ausprobieren von Programmen, die unter Orcas erstellt worden sind. Orcas installiert standardmäßig das .NET Framework 3.5 Beta1 vom April 2007. Wer sich bereits die neue Juni CTP runtergeladen hat, wird Programme die LINQ verwenden nicht ausführen können. Es erscheint folgende Fehlermeldung:

Der Typ System.Linq.Func`2 in der Assembly System.Core, Version 2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561924e089 konnte nicht geladen werden.

LINQ macht excessiven Gebrauch vom generischen Delegate Func<>. Dieser wurde nun in einen anderen Namespace verfrachtet. Statt bisher im Namespace System.Linq ist Func<> im Namespace System zu finden. Er ist somit überall verfügbar, ohne dass man einen bestimmten Namespace einbinden muss. Denn im Namespace System befinden sich alle Grundlegenden Datentypen.

Hinzugekommen sind nun auch diverse Überladungen des Action-Delegate. Es ist nämlich bisher nicht möglich einen Delegate Func zu erstellen. Jedoch kann man einen normalen Delegate delegate void Action(T obj) erstellen.

Hier nochmal die vorgefertigten Delegates in der Übersicht:

TReturn Func
TReturn Func
TReturn Func
TReturn Func
TReturn Func

void Action
void Action
void Action
void Action

WPF: Wie erstelle ich einen autoskalierenden Text?

2007-07-09T11:45:00.000+01:00

Es hat lange gebraucht bis ich mich an WPF (Windows Presentation Foundation) rangewagt habe. Ich erkenne aber immer mehr die Vorzüge von WPF. Z.B. erstelle ich gerade für eine Anwendung einen animierten Splash-Screen bzw. Intro. Das gibt natürlich wesentlich mehr her als ein statisches Bitmap auf dem das Anwendungslogo zu sehen ist. Ich brauche nicht zu erwähnen, dass dies mit GDI+ echt aufwändig wäre und lange nicht so gut aussehen würde wie mit WPF.

Der Splash-Screen soll natürlich voll Vektrobasiert sein, d.h. alle Grafiken, Text und Animationen, sollen sich der Größe des Fensters anpassen. Doch wie schaffe ich es, dass die Schriftgröße eines Textes in einer TextBox automatisch skaliert wird? Ich habe lange gesucht, und keine passende "einfache" Einstellung gefunden, wie z.B. TextBox.Strech = Fill; Hieran sieht man, dass WPF noch nicht ganz ausgereift ist. Es sind zwar viele Grundelemente vorhanden, die man zu anderen komplexen Elementen zusammenstellen kann, aber das muss man halt selber machen. Zudem braucht man eine Menge Wissen über WPF, was man am Anfang natürlich nicht hat. Wenn man also eine DataGridView in WPF braucht, wird man nicht direkt rangehen können, um sich eine eigene DataGridView zu bauchen; auch wenn die dafür erforderlichen Grundelemente vorhanden sind. 1. Braucht man viel Efahrung mit WPF und 2. kostet es enorm viel Zeit.

Aber zurück zu unserem skalierbaren Text.

Wir benötigen zunächst das Tool ExpressionBlend. Meine Lösung kann nicht programmiert werden, sondern benötigt ein Feature von ExpressionBlen

1. Wir nehmen einen TextBlock. (Achtung keine normale TextBox!)
2. Wir schreiben einen Text in unseren TextBlock. Es können auch andere Elemente wie Elipsen, Controls etc. zwischen dem Text stehen. Das ist mit einem TextBlock möglich. Dann die Schriftart und andere Einstellungen setzen.
3. Wir konvertiere nun den TextBlock in einen Path. Menü->Objekt->Pfad->in Pfad konvertieren. Alle Elemente des TextBlock auch der Text wird in einen Pfad konvertiert. Dieser Pfad besteht aus relativen Punkten die Vektororientiert sind und somit voll skalierbar.
4. Wir umgeben den Pfad mit einer ViewBox. Diese ViewBox kann automatisch ihre Childelemente skalieren.
5. Tada! Fertig ist unser automatisch skalierender Text

Nachteil: wenn man den Text ändern will muss man die Schritte erneut durchführen ;-(

Es wäre natürlich auch denkbar eine Skalierung in Abhängigkeit der Fenstergröße per Databinding zu ermöglichen. Hierzu müsste man aber entsprechende Berechnungen anstellen.

Was gibt's Neues in VisualBasic 2008?

2007-06-27T19:10:00.000+01:00

Ich probiere seit einiger Zeit die neue VisualStudio Version Orcas bzw. VS2008 in der Beta1 aus. Was mich natürlich besonders daran interessiert, sind die neuen VB Features. Nach langem Suchen musste ich feststellen, dass bestimmte Funktionen noch nicht in Orcas Beta 1 zu finden sind. Das betrifft z.B. Lambda Funktionen - also inline Funktionen. Während ich in C# eine lambda-funktion so schreiben kann x => x+1 (Eine Funktion mit dem Parameter x der x + 1 zurückgibt) sollte man in VB dies schreiben können Function(x) x+1. Anscheinend kann dies der Beta Compiler noch nicht. Was blieb mir anderes übrig als mit LINQ in C# weiter zu experimentieren. (Ich muss sagen, langsam gefällt mir C#.)

Werden solche kleinen Probleme in der endgültigen Version von VB 2008 behoben sein?

Ja, die gröbsten Sachen werden wohl in VB laufen, aber man wird keine großen Sprünge machen können. Es sieht so aus als würde C# 3.0 einen Produktivitätsgewinn gegenüber VB 9.0 haben. Was besonders ironisch ist C# wird dynamischer sein als VB. (Das wird aber mit VBx sicherlich wieder aufgeholt werden) Warum?

Keine Collection Initializer in VB!
Während C# so ziemlich jeden Typ ableiten kann, kann dies VB anscheinend nicht.
Im C# kann ich einenen anonymen Typen definieren:
var obj = new { Property1 = "Hallo", Property2 = 12345};
VB
Dim obj = New With { Property1 = "Hallo", Property2 = 12345}

Was ist wenn ich ein Array erstellen will?
C#
var list = new[] {1,2,3};
VB
Dim list = New Integer() {1,2,3}

Ärgerlich ist hier, dass ich bei VB den Datentyp des Arrays angeben muss. Warum kann dieser nicht abgeleitet werden wie bei C#?

Mit C# kann man auch Auflistungen erstellen, die vom Compiler abgeleitet werden können.
var list = new[]
{
new {Property1 = "hallo"};
new {Property1 = "test"};
};

Sowohl der Anonyme Typ als auch die Anonyme Collection können abgeleitet werden. Man kann also einen ObjektInitializier (also {Property=Value}) auch verschachteln und damit Collections bauen.

http://oakleafblog.blogspot.com/2007/06/will-visual-basic-90-have-collection.html sagt, dass auf mysteriöse Weise in den neusten HandsOnLabs zu VB 9 alle Verweise auf Collection Initializer verschwunden sind. Noch schlimmer: Keins der angeführten Beispiele soll funktionieren. Wie man also in Zukunft dieses C# Beispiel in VB umsetzten wird, ist also noch unklar.

Was gibt es sonst Neues? http://www.panopticoncentral.net/archive/2007/06/27/21113.aspx

Das InternalsVisibleToAttribute wird endlich vom VB Compiler erkannt. Damit ist es möglich, dass man die mit Friend gekennzeichneten Klassen und Member aus einer anderen Assembly aufrufen kann. Dies ist für UnitTests wichtig! Zwar konnte man bisher schon dieses Attribut in VB verwenden, aber die entsprechenden Friend Klassen wurden nicht angezeigt.
Relaxed Delegates. Hat man z.B. einen Click EventHandler für einen Button und man möchte dieses Ereignis verarbeiten, musste man immer die entsprechende Signatur des EventHandler Delegates als Verarbeitungsmethode schreiben. In der Regel also Button1_click(sender as Object, e as EventArgs). Das war lästig, da weder sender noch e benutzt wurden (Es sei den EventArgs hatte wirklich wichtige Argumente). Es wird aber nicht das sog. Currying unterstützt, d.h. dass man auch nur einen Parameter verwenden kann, statt alle Parameter wegzulassen.
VB Programme können auch ohne Microsoft.VisualBasic.dll kompiliert werden. Der VB Compiler hat bisher für bestimmte late-binding Funktionen von VB dieses Dll benötigt.
Es können Objektmember auf Interfaces aufgerufen werden. Es gibt zwar keine Beispiele hierzu, aber ich stell mir das als Extrem LateBinding vor. Beispiel:

Interface ITest

Sub CallFunktion

End Interface

Class Person Implements ITest

Property Name

End Class

Dim p as ITest = New Person

p.Name

Ich könnte ein Objekt zu einem Interface casten und dann auf diesem Interface ein Member des Objekts aufrufen, obwohl die Variable ja jetzt ein Interface ist. (Wofür soll das gut sein???)

Es wird einen ? Operator wie in C# geben, um If Else Condition in Kurzform schreiben zu können. (Was für ein Blödsinn!)

Was wird nicht umgesetzt?
Erlaubt es C#, dass in Labdas auch Statements wie - Console.WriteLine(x) - möglich sind, werden in VB nur Expressions erlaubt sein - also x+1. Dadurch wird VB um echte Funktionalität für LINQ beschnitten. Auch einen yield Operator wird es in VB nicht geben. Dadurch wird VB Programmierern die Möglichkeit genommen, wirklich produktiv und kreativ mit LINQ zu arbeiten. (Shame on you Microsoft!)

Insgesamt bin ich schon sehr enttäusch von den neuen VB Features! Echt schwache Leistung Microsoft. Ich werde wohl für den Einsatz von LINQ C# einsetzten MÜSSEN, obwohl ich lieber VB verwenden würde!