WPF Linie zeichnen in Canvas

Ishildur

@David W
Ich probiere das gleich mal aus, allerdings bin ich mir ziemlich sicher, dass dadurch genau die von mir genannten Verzerrungsartefakte bei jedem non-uniform scaling entstehen werden...

Ishildur

Ja, verzerrt :p

EXDW

Dann erlaubste halt nur ein Uniform Fill

Ishildur

Dann läuft die Applikation nur noch mit einem einzigen Seitenverhältnis korrekt

EXDW

Was für artefakte treten eigentlich auf?

Ishildur

http://www.pandora-studios.ch/wpf/wpf.jpg
http://www.pandora-studios.ch/wpf/artefakt0.jpg
http://www.pandora-studios.ch/wpf/artefakt1.jpg

Beachte vor allem die oberen Abrundungen (nix mehr rund sein) sowie natürlich auch
die Bezierkurve, welche jeweils eine völlig andere Form annimmt.

EXDW

Und was erwartest du?

Ishildur

Ich will natürlich den Pfad so definieren können, dass diese Artefakte nicht entstehen, so wie ich das mit jeder anderen mir bekannten Grafikbibliothek (GDI,GDI+,DirectX,OpenGL,AWT/SWING) auch tun kann!

Bspw. anstatt

<LineSegment Point="200,10"/>
<ArcSegment Point="210,20" Size="10,10" SweepDirection="Clockwise"/>

bräuchte ich sowas:

<LineSegment Point="Canvas.Right-20,10"/>
<ArcSegment Point="Canvas.Right-20,20" Size="10,10" SweepDirection="Clockwise"/>

usw..
Wenn man es so definiert, entstehen diese Artefakte nicht!
Nur leider scheint das mit WPF oder zumindest mit XAML nicht möglich zu sein?

EXDW

Das beantwortet die Frage nicht.
Angenommen du machst das Fenster größer - was soll Passieren?

Ishildur

Ach so

Horizontale Skalierung:
- Obere horizontale Linie stretchen, rechte obere Rundung verschieben (keine Skalierung!)
- Polynomkoeffizienten für die Kontrollpunkte der Bezierkurven neu berechnen um Kurvenform wiederherzustellen (bei grösserer horizontaler Ausdehnung, müssen die Kontrollpunkte auf der vertiaklen Achse weiter auseinanderliegen).

Vertikale Skalierung:
Nur die beiden vertikalen Linien stretchen, Kontrollpunkte der Bezierkurve werden vertial verschoben (keine Neuberechnung erforderlich).

EXDW

Dh also du willst beim Stretch nur die Horizontalen und vertikalen Linien stretchen lassen, die ecken aber nicht.

Xaml only geht das nicht (müsste man partiell vom stretch aus nehmen).
Was du aber machen kannst ist das von mir bereits angesprochene konvertieren.

<Window.Resources>
	<Local:LengthConverter x:Key="LengthConverter" />
</Window.Resources>
<Grid x:Name="head">
	<Path Margin="10">
		<Path.Effect>
			<DropShadowEffect ShadowDepth="1" BlurRadius="3" />
		</Path.Effect>
		<Path.Data>
			<PathGeometry>
				<PathFigure StartPoint="10,20">
					<PathSegmentCollection>
						<ArcSegment Point="20,10" Size="10,10" SweepDirection="Clockwise" />
						<LineSegment Point="{Binding ActualWidth, ElementName=header, Converter={StaticResource LengthConverter}, ConverterParameter=10.0}" />
						<ArcSegment Point="210,20" Size="10,10" SweepDirection="Clockwise" />
						<LineSegment Point="210,50" />
						<BezierSegment Point1="180,25" Point2="100,50" Point3="100,50" />
						<BezierSegment Point1="100,49" Point2="40,70" Point3="10,50" />
						<LineSegment Point="10,20" />
					</PathSegmentCollection>
				</PathFigure>
			</PathGeometry>
		</Path.Data>
		<Path.Fill>
			<LinearGradientBrush EndPoint="0.5,1" StartPoint="0.5,0">
				<GradientStop Color="#FF0066CB" />
				<GradientStop Color="#FF99CCFF" Offset="1" />
			</LinearGradientBrush>
		</Path.Fill>
	</Path>
</Grid>

public class LengthConverter : IValueConverter
{
	public object Convert(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
	{
		double controlWidth = (double)value;
		double secondValue = System.Convert.ToDouble(parameter);
		// hier berechnen wie die werte sein sollen
		return new Point((controlWidth) - 20.0, secondValue);
	}

	public object ConvertBack(object value, Type targetType, object parameter, System.Globalization.CultureInfo culture)
	{
		throw new NotImplementedException();
	}
}

Du könntest nun für jeden verschiedenen typen einen eigenen converter schreiben.
Oder im ConverterParameter angeben welche Linie es ist, der Converter kann dann in ein Switch Case die Werte neu berechnen.
(Der Converter wird bei jedem Resize des Grids aufgerufen.)
Im Xaml hast du eventuell am ende nur noch Zahlen die Fest sind.

//Dazu
Das Code Beispiel macht gerade kein Sinn, es zeigt aber wie du das gewünschte erreichen kannst.

Ishildur

Was ich nicht verstehe, was ist der Vorteil von XAML gegenüber C#? In XAML scheint mir alles deutlich komplizierter und gleichzeitig deutlich eingeschränkter zu sein und am Ende muss der Job dann offensichtlich doch von C# gemacht werden? Auch sehe ich den Vorteil des Retained Mode in WPF nicht ein. Eigentlich sehe ich nur Nachteile (geringere Flexibilität bei gleichzeitig massiv höherem Memory Footprint). Was mich zusätzlich skeptisch macht ist die Tatsache, dass man in die vermeintliche XML Sprache nun auch noch völlig andere und in keiner Weise XML kompatible Sprachkonstrukte reingefrickelt hat ({Binding Source=blahlah} ist nicht eben XML).

Irgendwie finde ich das Ganze ja interessant. In der Vergangenheit hatte praktisch jede Grafiklibrary in irgendeine Form einen RetainedMode (sogar DirectX bis Version 6 oder 7), der dann aber früher oder später IMMER dem Immediate Mode wich. Hier auch wieder. Ich meine, was ich da vorhabe ist weiss Gott nichts Komplexes und doch scheine ich bereits jtzt an die Grenzen von XAML gestossen zu sein? Schon muss man mit Krücken (IValueConverter) herumfrickeln welche IMHO nicht für diesen Einsatzzweck gedacht waren.

Wenn ich bereits hier an Grenzen stosse, dann frage ich mich schon, wie ich dann bspw. mit XAML einen Graphen rendern soll, dessen Nodes einen bestimmten Platz (Canvas) optimal nutzen sollen, ohne zur Entwicklungszeit die Anzahl sowie die Dimensionen der Nodes zu kennen. Oder wie soll ich normalisierte Diagramme rendern, wenn ich mit XAML nicht rechnen kann?

Also im Moment sieht das für mich aus, als wäre XAML gerade gut genug, um ein paar Rechtecke und Ellipsen zu zeichnen, judihui, aber das wars dann auch schon...

Sehe ich das falsch?

Dravere

Ishildur schrieb:

Sehe ich das falsch?

Laut den Experten schon, nach mir nicht wirklich. Ich stimme mit dir nur in einem Punkt nicht überein, in XAML ist viel mehr möglich als in WinForms. Aber es ist exponential komplizierter und meiner Meinung nach auch vielfach unlogisch.

Es gibt leider immer wieder Dinge, welche nicht durchgezogen sind, nicht fertig sind oder einfach nur einen riesen Aufwand darstellen.

Wenn man dasselbe erreichen möchte, was man bereits in WinForms erreicht hat, braucht man ca. 1,5 mal so viel Code. Wenn man etwas mehr erreichen möchte, als man in WinForms erreichen konnte, braucht man 10 mal so viel Code. Und dann nochmals ein wenig mehr ist man schon bei 100 mal angekommen. Und darüber muss man dann noch den Überblick behalten und es verstehen.

Das einzige was wirklich einfach und sehr gut ist, sind einfache Datenbindungsgeschichten. Aber wehe man probiert in dem Bereich das Level ein wenig höher zu setzen, dann stösst man sofort auch an Grenzen.

Ich habe immer noch keinen Zugang gefunden zu dieser WPF Geschichte, obwohl ich immer wieder damit rumprobiere. Es ist mir ein Rätsel, wie gewisse Leute solche Fans von WPF sein können. Die haben wohl nie mit WinForms programmiert

Grüssli

EXDW

First of all - WPF ist keine Grafiklibrary, es is eine Präsentations schicht um Windows Oberflächen zu entwickeln.

Wer sich ernsthaft mit WPF beschäftigt hat wird schnell merken wie fummelig und mühseeelig Forms oder eine C++ UI Library sein kann.
Man fragt sich sehr schnell wieso man sich so lange mit den Alten Zeug aufhielt.

Ich füge einfach mal (ein paar!) Beispiele auf:

1. Man kann das gewünschte erzeugen mit nur sehr wenig Code.
Das liegt zum einen daran das es eine recht kompakte Sprache ist, und es eine beliebige Schachtelung erlaubt.

<GroupBox>
    <GroupBox.Header>
        <CheckBox Content="Advance Settings" />
    </GroupBox.Header>
</GroupBox>

2. Man kann durch die Binding klasse alles mögliche miteinander vebinden, wenn das Datenformat nicht stimmt kann man es auch konvertieren:

<GroupBox>
    <GroupBox.Header>
        <CheckBox Content="Advance Settings" x:Name="advance" />
    </GroupBox.Header>
    <StackPanel>
        <ComboBox IsEnabled="{Binding IsChecked, ElementName=advance}"
                  ItemsSource="{Binding AnySettings}" />
    </StackPanel>
</GroupBox>

Nun Zeigt die ComboBox eine Liste von "AnySetting" Objekten, und ist deaktiviert wenn die CheckBox deaktiviert ist.

3. Einfache trennung von Oberfläche und Daten
Angenommen ich habe eine Liste von Personen (Beliebtes Beispiel) und habe diese in einer Liste

public List<Person> Persons { get; set; }

Kann ich nun im Code damit arbeiten ohne das es mich überhaupt interessiert wie es in der UI angezeigt wird, es kann in einer ComboBox sein, einer ListBox, oder was auch immer...

<AnyControl ItemsSource="{Binding Persons}" />

4. Das aussehen von Controls kann an jeder stelle beliebig verändert werden, auch in abhängigkeiten von den Daten.
Beispiel zeige ich unten gleich.

5. Man kann mit ein Paar klicks Farbverläufe oder Animationen zusammen basteln. Interessantes Thema, lass ich aber mal außen vor.

6. Die Oberfläche ist Dynamisch.
- Controls passen sich und ihre Größe automatisch an, in MFC und Forms gibt es immer wieder das Problem das Buttons abgeschnitten ist weil der Text zu breit ist.
- Control Inhalte passen den Daten an, wenn sich in den Daten was ändert aktualisiert sich die UI automatisch (Observer Pattern)
- Man kann zur laufzeit die Sprache ändern und der Text ändert sich ohne ein Fetzen Code

Mal ein einfaches Beispiel (Was ich hier im Forum tippe, teste nichts).
Ich möchte eine Applikation:
- Oben ein Menü ("File" item, mehr nicht)
- Unten eine Statusleiste ("Ready" text, mehr nicht)
- Über die Statusleiste zwei Buttons (ohne funktionalität) mit OK und Abbrechen auf der Rechnen Seite mit 10 Abstand
- Beide Buttons in jeder sprache gleich lang und ohne das etwas abgeschnitten ist
- Links eine Liste von Personen
- Unterschiedliche Detail ansichten wenn die Person Männlich oder Weiblich ist
- Rechts Detailansicht der ausgewählten Person
- Alles Resizable (Breite und Höhe des Fensters und Breiter machen der Linken liste)

Als erstes macht man sich die Daten (Es gibt immer mehrere Lösungswege, das ist einer)

public class Person
{
    public Person(string name)
    {
        Name = name;
    }
    public string Name { get; set; }
}

public class MalePerson : Person
{
    public MalePerson(string name)
        : base(name)
    { }
}

public class FemalePerson : Person
{
    public FemalePerson(string name)
        : base(name)
    { }
}

Nun mache ich die Personen bekannt:

public class Persons
{
    public Persons()
    {
        Persons = new List<Person>();
    }

    public List<Person> Persons { get; set; }

    public void SetPersons(List<Person> persons)
    {
        Persons.AddRange(persons);
    }
}

Das sind die Daten, mehr gibt es nicht, mehr braucht man nicht laut Anforderung.

Nun die View

<Window ...>
    <DockPanel>
        <Menu DockPanel.Dock="Top">
            <MenuItem Header="File" />
        </Menu>

        <StatusBar DockPanel.Dock="Bottom">
            <TextBlock Text="Ready" />
        </StatusBar>

        <UniformGrid Rows="1" Margin="10" DockPanel.Dock="Bottom">
            <Button Content="OK" IsDefault="True" Margin="5,0,0,0" Padding="12.1" />
            <Button Content="Cancel" IsCancel="True" Margin="5,0,0,0" Padding="12.1" />
        </UniformGrid>

        <Grid>
            <Grid.ColumnDefinitions>
                <ColumnDefinition Width="150" />
                <ColumnDefinition Width="Auto" />
                <ColumnDefinition />
            </Grid.ColumnDefinitions>

            <ListBox ItemsSource="{Binding Persons}" x:Name="items">
                <ListBox.ItemsTemplate>
                    <DataTemplate>
                        <TextBlock Text="{Binding Name}" />
                    </DataTemplate>
                </ListBox.ItemsTemplate>
            </ListBox>

            <GridSplitter Grid.Column="1" ResizeBehavior="PreviousAndNext" Width="4" />

            <ContentControl Grid.Column="2" Content="{Binding SelectedItem, ElementName=items}">
                <ContentControl.Resources>

                    <DataTemplate DataType="{x:Type Local:FemalePersons}">
                        <!-- Hier das Template für Weibchen -->
                    </DataTemplate>

                    <DataTemplate DataType="{x:Type Local:MalePersons}">
                        <!-- Hier das Template für Männchen -->
                    </DataTemplate>

                </ContentControl.Resources>
            </ContentControl>
        </Grid>
    </DockPanel>
</Window>

In Forms hat man da deutlich mehr code (Auch wenns eventuell im Designer Code versteckt ist).
Auch aus C# heraus wäre es um Welten länger.
Man hat deutlich mehr Freiheiten, wie man sieht im Code ist nur noch Datenhalung, sonst nichts.
Wie es Angezeigt wird ist aufgabe der View, sie kümmert sich allein drum. Könnte nun die Personen Liste nach einer ComboBox ändern und nach oben packen und die Details drunter, das würde im Code nichts ändern.

@Dravere, nichts deiner aussagen entpricht der Wahrheit! Ich wollte erst einzeln Zitieren, aber die antworten wäre bei jeder einzelnen die selbe gewesen => Bullshit.
Wenn man sich mal damit beschäftigt wie WPF funktioniert, ist alles absolut logisch.
Du kannst viel komplexere Dinge mit Deutlich weniger Code erstellen (Wenn du in Xaml bleibst, du kannst die Oberfläche auch mit C# alleine machen)

Kurz gesagt: Du hast absolut keine ahnung was du verpasst und wie schwer du dir das Leben machst wenn du bei Forms bleibst. Nach deiner aussage zu urteilen hast du von WPF an sich absolut keinen Dunst.
Man hat am anfang zwar eine höhere Lernkurve, und man muss auch noch verstehen lernen wie WPF funktioniert, aber das hat man sehr schnell, und dann will man nichts anderes mehr machen.
Man war in seiner Kreativität und in der Software Architektur noch nie freier.

//Edit, ein paar Tags vergessen

//Dazu
Was ich noch sagen sollte, das man nicht sagen kann "Des - 20" ist normal, XAML ist eine "Deklarative Sprache", man definiert nur zustände.
"Button Rot, und Ein border als Content mit den Ecken 8 Rund"

<Button Background="Red">
    <Border CornerRadius="8">
    </Border>
</Button>

In Triggers ist das auch so
Wenn status = Das, dann Button Gelb und der Border hat keine Ecken mehr.

<Trigger Property="status" Value="Das">
    <Setter TargetName="button" Property="Background" Value="Yellow" />
    <Setter TargetName="border" Property="CornerRadius" Value="0" />
</Trigger>

Methoden gibt es nicht (also auch keine - + operatoren) und auch keine if else ketten in triggers

Insgesammt ist es das was mich zZt dazu bewegt nichts mehr in Foren zu schreiben, die Deppen werden von C# und nun von WPF magisch angezogen.
Da kommen leute ohne ahnung, wollen wie in Forms oder MFC Programmieren, finden das aufwändig und verurteilen WPF an sicht.
KAUFT EUCH EIN BUCH UND LERNT ES in WPF entwickelt man nunmal anders als in Forms, und wenn man das kann weiß man auch warum es deutlich besser, angenehmer, einfacher und vor allem Schneller ist.

Solche Leute stehen mir mitlerweile bis hier oben "Buäää, alles so dooof", "Alles so kompliziert", "Geht denn das nicht, scheiß WPF" => LERNT ES DOCH ENDLICH

(Wer sich angesprochen fühlt ist auch gemeint)

Dravere

@David W,
Ich lerne WPF, ich habe schon ein Buch durch, welches sich ausschliesslich mit WPF beschäftigt hat. Trotzdem bin ich davon nicht begeistert. Du wirst wohl einfach aktzeptieren müssen, dass die Geschmäcker unterschiedlich sind. Wenn ich die folgenden Aussagen lese:

David W schrieb:

Wer sich ernsthaft mit WPF beschäftigt hat wird schnell merken wie fummelig und mühseeelig Forms oder eine C++ UI Library sein kann.
Man fragt sich sehr schnell wieso man sich so lange mit den Alten Zeug aufhielt.

David W schrieb:

Insgesammt ist es das was mich zZt dazu bewegt nichts mehr in Foren zu schreiben, die Deppen werden von C# und nun von WPF magisch angezogen.
Da kommen leute ohne ahnung, wollen wie in Forms oder MFC Programmieren, finden das aufwändig und verurteilen WPF an sicht.
KAUFT EUCH EIN BUCH UND LERNT ES in WPF entwickelt man nunmal anders als in Forms, und wenn man das kann weiß man auch warum es deutlich besser, angenehmer, einfacher und vor allem Schneller ist.

Dann kann ich nur noch sagen, typisches Fanboy verhalten, welche nicht aktzeptieren können, dass es andere Geschmäcker gibt und andere Vorstellungen. WPF ist nicht die absolute saugute Lösung. Sogar die WPF Entwickler selber üben Kritik an WPF, daher kann dies nicht der letzte Schluss sein.

Ich habe WPF gelernt, ich habe aber immer wieder Probleme damit. Diese Probleme kommen nicht von irgendwoher. Und man kann mir dann zum Teil nicht mal helfen, da die WPF Experten nicht mal wissen, wie man das am sinnvollsten löst. Da kommt bei mir natürlich schon die Frage auf, wie sinnvoll WPF ist

Hast nicht du mal gesagt, dass du dich nie ernsthaft mit WinForms beschäftigt hast? Wie willst du dann dies vergleichen wollen? Ich entwickle die Mehrzahl der neuen Projekte in WPF. Ich denke daher schon, dass ich ein gewisses Urteil darüber fällen kann. Klar, diese Urteile sind subjektiv, aber das ist ja auch ganz normal. Sowas muss man aktzeptieren können, dass gewissen Leuten etwas einfach nicht passt. Wobei ich noch nicht mal soweit gehen würde. Ich finde WPF an sich interessant, nur nicht zuende gedacht. Die Ansätze sind gut, die Umsetzung gefällt mir nicht.

Deine Beispiele sind so typische Bilderbuchbeispiele. Die gehen wunderbar, das ist wunderbar. Sobald es aber um ECHTE Probleme geht, kommt man schnell zu Problemen, vor allem wenn man etwas machen möchte, worin WPF doch so unglaublich gut sein soll, nämlich der individuellen Anpassung. Solange man dies erreichen will, was man in WinForms schon machen konnte, verliert WPF eher. Das ist zumindest meine Meinung, mit welcher du leben kannst oder dich aufregen oder probieren mir bei meinen Problemen zu helfen. Wenn du mir hilfst und mir aufzeigst, wie einfach es doch tatsächlich mit WPF geht, dann würdest du mich eher überzeugen. Aber du ärgerst dich anscheinend lieber auf und steckst nebenan still die Faust in den Sack

Hilf mir bei meinen Problemen und überzeuge mich, ich bin bereit diese Hilfe anzunehmen und darauf zu hören. Wenn du schweigst, bringt dies niemandem was.

Grüssli

EXDW

Dravere schrieb:

...Dann kann ich nur noch sagen, typisches Fanboy verhalten, welche nicht aktzeptieren können, dass es andere Geschmäcker gibt und andere Vorstellungen. WPF ist nicht die absolute saugute Lösung. Sogar die WPF Entwickler selber üben Kritik an WPF, daher kann dies nicht der letzte Schluss sein.

Die Kritiken die WPF Entwickler üben sind eher Performance und Problemfindung wenn in Xaml etwas nicht geht. Mehr nicht. Wenn es andere Kritiken sind oft auch auf unwissenheit zurück zu führen.

Dravere schrieb:

Ich habe WPF gelernt, ich habe aber immer wieder Probleme damit. Diese Probleme kommen nicht von irgendwoher. Und man kann mir dann zum Teil nicht mal helfen, da die WPF Experten nicht mal wissen, wie man das am sinnvollsten löst. Da kommt bei mir natürlich schon die Frage auf, wie sinnvoll WPF ist

Wie sinnvoll WPF ist kannst du an meine oben aufgeführten Punkte ablesen. Probleme die nicht sinnvoll zu lösen sind, hast du in jeder Sprache.

Dravere schrieb:

Deine Beispiele sind so typische Bilderbuchbeispiele. Die gehen wunderbar, das ist wunderbar. Sobald es aber um ECHTE Probleme geht, kommt man schnell zu Problemen,

Ich habe solch ein Beispiel nur gewählt da es so kurz ist, mein Beitrag war schon lang genug.
Ich selber entwickel nur noch WPF Seit ende 2008, und es konnten bisher alle Probleme im verhältnis schnell gelöst werden.

Dravere schrieb:

vor allem wenn man etwas machen möchte, worin WPF doch so unglaublich gut sein soll, nämlich der individuellen Anpassung. Solange man dies erreichen will, was man in WinForms schon machen konnte, verliert WPF eher.

Wir in unserer Firma setzen alle neuen Applikationen nur noch in WPF auf (Applikationen für den Endanwender), eben weil es extrem einfach ist eigene Control zu schreiben oder alles individuell an zu passen.
Was du für Probleme du dabei hast ist mir schleierhaft.
Ich will mal sehen wie du in Forms mal eben einfach so bilder nebst formatierten Text in ComboBoxen packst und eine Detailansicht daneben. Ohne auch nur ein fetzen Code in ein paar Zeilen. Oder die schon gezeigte ComboBox im einem GroupBox Header, die alles darin enthaltene mal eben deaktivieren kann. Auch da ohne ein fetzen Code.

Dravere schrieb:

Das ist zumindest meine Meinung, mit welcher du leben kannst oder dich aufregen oder probieren mir bei meinen Problemen zu helfen. Wenn du mir hilfst und mir aufzeigst, wie einfach es doch tatsächlich mit WPF geht, dann würdest du mich eher überzeugen. Aber du ärgerst dich anscheinend lieber auf und steckst nebenan still die Faust in den Sack

Hilf mir bei meinen Problemen und überzeuge mich, ich bin bereit diese Hilfe anzunehmen und darauf zu hören. Wenn du schweigst, bringt dies niemandem was.

Welche Probleme hast du denn? Privaten kontakten helf ich sehr gerne, hier im Forum hab ich die Tage kaum gelesen, also kein Überblick.

Dravere

David W schrieb:

Welche Probleme hast du denn? Privaten kontakten helf ich sehr gerne, hier im Forum hab ich die Tage kaum gelesen, also kein Überblick.

Falls ich darf, würde ich dir schon mal eine E-Mail schreiben, wenn du lieber so Hilfe gibst. Meine beiden letzten Probleme, welche mich am meisten geärgert haben, sind die folgenden beiden Threads:
1. Hier wollte ich mal wieder die individuelle Anpassung verwenden und bin völlig gestrandet.
http://www.c-plusplus.net/forum/284142
2. Und hier rege ich mich darüber auf, dass man zum einen immer noch keine fertigen Common Dialoge hat und vor allem nichts, was dem Enduser bereits bekannt vorkommt. Geschweige denn etwas mit i18n.
http://www.c-plusplus.net/forum/283112
Wobei ich hier auch noch ein Problem von WPF sehe, dass man keine vernünftige Rückwärtskompatibilität anbietet. Font & co aus System.Drawing zu allen neuen Fontklassen. Oder auch ein bekanntes Beispiel die Inkompatibilität zwischen System.Drawing.Bitmap und den System.Windows.Media.Imaging Typen. Sowas ist einfach nur ärgerlich und hätte von den WPF Entwicklern mit einer einfachen zusätzlichen statischen Methode abgefangen werden können.

Vielleicht erwarte ich auch einfach zuviel von WPF, wenn es als eine so glorreiche Bibliothek dargestellt wird. Allerdings bin ich zumindest einigermasen sicher, dass ich kein Depp bin.

Grüssli

EXDW

Ich habe auf die Threads geantwortet - setzen da die Problemlösungen fort.
Was mail und ICQ an geht, auf meiner Seite bei Kontakt findeste alles was du brauchst. Wenn du dich auf ein WPF Fanboy einlassen willst (auch nachdem ich dampf ab lies ^^)