[WPF] Common Dialogs

Dravere

.Net 4.0 ist draussen und somit auch die dritte Version von WPF ... und immer noch fehlen verschiebene Common Dialogs im .Net Framework für WPF. Weiss einer zufälligerweise wieso Microsoft sowas nicht endlich mal anbieten kann?

Naja, ich suche aktuell solche Dialoge für Farbe und Font. Ich habe bisher nur je ein Beispiel von Microsoft gefunden, allerdings gefallen sie mir nicht wirklich. Wirken für mich beide viel zu überladen und mehr hingepappt als wirklich auf Usability Wert gelegt. Auf Codeproject habe ich nur einen Dialog für Farbe gefunden. Wirkt auf mich aber etwas klobig und ist weit weg vom normalen Aussehen des Standard-Dialogs von Windows. Auf Codeplex konnte ich keine Lösungen ausfindig machen. Auch sonstige Suchaktionen haben zu keinem Resultat geführt. Kennt ihr andere Implementierungen?

Für den Dialog für Farbe könnte ich notfalls noch auf die WinForms implementierung zurückgreifen. Beim Dialog für Fonts habe ich allerdings so meine Mühe, vor allem weil ich nicht so ganz verstehe, wie ich sauber die Umwandlung eines System.Drawing.Font in das multiple Zeug von WPF erreichen kann.
Wieder etwas was mich an WPF stört ... wieso muss jedes Control 6 Properties mit sich führen, welche alle für die Font Konfiguration verwendet wird. Wieso konnte man dies nicht in eine einzige Klasse zusammenführen?

Grüssli

EXDW

Dravere schrieb:

.Net 4.0 ist draussen und somit auch die dritte Version von WPF ... und immer noch fehlen verschiebene Common Dialogs im .Net Framework für WPF. Weiss einer zufälligerweise wieso Microsoft sowas nicht endlich mal anbieten kann?

Implementiert haben sie es ja schon, sieht man ja an Blend uns VS 2010, nur sie veröffentlichen es nicht. Man muss überlegen warum, ich kann mir nur vorstellen das der bedarf nicht so hoch ist. Vor allem wo man ja auf die Win32 ColorPicker und FontPicker zurück greifen kann.

Dravere schrieb:

Naja, ich suche aktuell solche Dialoge für Farbe und Font. Ich habe bisher nur je ein Beispiel von Microsoft gefunden, allerdings gefallen sie mir nicht wirklich. Wirken für mich beide viel zu überladen und mehr hingepappt als wirklich auf Usability Wert gelegt. Auf Codeproject habe ich nur einen Dialog für Farbe gefunden. Wirkt auf mich aber etwas klobig und ist weit weg vom normalen Aussehen des Standard-Dialogs von Windows. Auf Codeplex konnte ich keine Lösungen ausfindig machen. Auch sonstige Suchaktionen haben zu keinem Resultat geführt. Kennt ihr andere Implementierungen?

Also auf Custom Controls würde ich nicht zurück greifen, viel mehr auf die Controls aus Win32 oder Forms zurück greifen.

Dravere schrieb:

Für den Dialog für Farbe könnte ich notfalls noch auf die WinForms implementierung zurückgreifen. Beim Dialog für Fonts habe ich allerdings so meine Mühe, vor allem weil ich nicht so ganz verstehe, wie ich sauber die Umwandlung eines System.Drawing.Font in das multiple Zeug von WPF erreichen kann.

Hast du mal geschaut ob es schon konvertierende Klassen gibt? Ich hatte solche mal geschrieben, finde sie aber nicht mehr

Dravere schrieb:

Wieder etwas was mich an WPF stört ... wieso muss jedes Control 6 Properties mit sich führen, welche alle für die Font Konfiguration verwendet wird. Wieso konnte man dies nicht in eine einzige Klasse zusammenführen?

Das ist normal, das liegt an die Deklaration der Elemente.
Angenommen es gäbe eine Klasse für alles was die Font an geht, dann kann man es nicht mehr sauber Xaml definieren.
Du müsstest nur um es Italic zu machen ein Haufen Code schreiben.

<TextBlock Text="Item" FontStyle="Italic" />

vs.

<TextBlock Text="Item">
    <TextBlock.Font>
        <Italic />
    </TextBlock.Font>
<TextBlock>

Das selbe für Font größen usw.

Desweiteren kommt da die vererbungshirarchie ins Spiel.
Nehmen wir an du hast ein StackPanel und alle Elemente darunter sollen Italic sein.

<StackPanel TextBlock.FontStyle="Italic">
    <TextBlock Text="First" />
    <Button Content="Second" FontWeight="Bold" />
</StackPanel>

Schon sind alle Italic.
Das zweite ist nun Italic und Bold, also man überschreibt die alten Settings nicht.

Das ist nur ein einfaches Beispiel, vielmehr ist es so das man Globale Styles hat wo definiert ist "Alle TextBoxen haben eine Italic schrift", das wirkt einmal global, aber stört sich nicht mit den anderen Properties, wenn es überschreiben würde, müsste man alle Styles aus dem Parent Style kennen und übernehmen. Besonders schlimm wird es wenn die Styles sich zur laufzeit ändern können.

Dravere

David W schrieb:

Implementiert haben sie es ja schon, sieht man ja an Blend uns VS 2010, nur sie veröffentlichen es nicht. Man muss überlegen warum, ich kann mir nur vorstellen das der bedarf nicht so hoch ist. Vor allem wo man ja auf die Win32 ColorPicker und FontPicker zurück greifen kann.

Den Grund verstehe ich nicht so recht. Wieso veröffentlicht man es nicht, wenn man es hat? Zudem gibt es genügend Threads in den MSDN Foren, welche nach sowas fragen. Ich habe jedenfalls einige gefunden und alle haben auf die von mir erwähnten Implementationen verwiesen. Empfinde ich als recht verwirrend.

Man kann auf die anderen zurückgreifen, klar, aber dann muss man wieder die WinForms DLLs miteinbinden. Ich dachte davon möchte man wegkommen.

David W schrieb:

Hast du mal geschaut ob es schon konvertierende Klassen gibt? Ich hatte solche mal geschrieben, finde sie aber nicht mehr

Natürlich, aber bisher nichts brauchbares gefunden. Eine FontFamily kann ich auch noch konvertieren, da nimmt man einfach den Namen und fertig. Aber beim weiteren Zeug wird es dann komplizierter. Es gibt noch ein paar Codes im Netz, welche einen System.Drawing.Font zu einem System.Windows.Media.Typeface konvertieren. Leider enthält Typeface nicht alle Informationen, welche in System.Drawing.Font drin sind. Der Rest scheint dann über TextDecoration zu laufen, welches man aber auch nicht überall vorfindet. Und wie genau man hier die korrekte Konvertierung durchführt, konnte ich bisher nirgends finden.

David W schrieb:

Dravere schrieb:

Wieder etwas was mich an WPF stört ... wieso muss jedes Control 6 Properties mit sich führen, welche alle für die Font Konfiguration verwendet wird. Wieso konnte man dies nicht in eine einzige Klasse zusammenführen?

Das ist normal, das liegt an die Deklaration der Elemente.
Angenommen es gäbe eine Klasse für alles was die Font an geht, dann kann man es nicht mehr sauber Xaml definieren.

Dann ist es eine Schwäche von Xaml. Wieso konnt man in der Syntax nicht sowas erlauben:

<TextBlock Text="Item" Font.FontStyle="Italic" />

Notfalls, wenn du nun sagst, dass man dies bereits für die DependencyProperties verwendet, hätte man ja auch einen Self-Scope machen können:

<TextBlock Text="Item" Self.Font.FontStyle="Italic" />

Dies hätte man auch in der Vererbungshierarchie prima implementieren können.

David W schrieb:

Das ist nur ein einfaches Beispiel, vielmehr ist es so das man Globale Styles hat wo definiert ist "Alle TextBoxen haben eine Italic schrift", das wirkt einmal global, aber stört sich nicht mit den anderen Properties, wenn es überschreiben würde, müsste man alle Styles aus dem Parent Style kennen und übernehmen. Besonders schlimm wird es wenn die Styles sich zur laufzeit ändern können.

Das mit den Styles kenne ich. Bei mir ist es aber so, dass man Elemente selber hinzufügen kann und von diesen bestimmen können muss:
1. Hintergrundfarbe
2. Textfarbe
3. Schriftart und co

Das ganze wird dann noch gedruckt. Drucken ist wirklich simpel in WPF, wo ich mal wirklich sagen muss, dass dies in WPF recht gut gelungen ist. Immerhin etwas

Grüssli

EXDW

Dravere schrieb:

Den Grund verstehe ich nicht so recht. Wieso veröffentlicht man es nicht, wenn man es hat? Zudem gibt es genügend Threads in den MSDN Foren, welche nach sowas fragen. Ich habe jedenfalls einige gefunden und alle haben auf die von mir erwähnten Implementationen verwiesen. Empfinde ich als recht verwirrend.

Ich vermute das ist eine Milchmädchen rechnungen. Sie überlegen sich wieviele WPF einsetzen, und davon fragen gerade mal 2% nach -> Lohnt nicht. Dazu kommen ja noch Maintenance kosten wenn etwas nicht funktioniert oder geändert werden soll, auch das mit ziehen in den nächsten Versionen.
Das es da ist heißt ja noch lange nicht das es ins Framework kann, MS ist eine so große Firma da gibts auch intern Copyright (Darum sind die Ribbons ja auch [noch] nicht fest in .Net sondern separat, weil das Office Team die lizenz hällt)

Dravere schrieb:

David W schrieb:

Dravere schrieb:

Wieder etwas was mich an WPF stört ... wieso muss jedes Control 6 Properties mit sich führen, welche alle für die Font Konfiguration verwendet wird. Wieso konnte man dies nicht in eine einzige Klasse zusammenführen?

Das ist normal, das liegt an die Deklaration der Elemente.
Angenommen es gäbe eine Klasse für alles was die Font an geht, dann kann man es nicht mehr sauber Xaml definieren.

Dann ist es eine Schwäche von Xaml. Wieso konnt man in der Syntax nicht sowas erlauben:
<TextBlock Text="Item" Font.FontStyle="Italic" />
Notfalls, wenn du nun sagst, dass man dies bereits für die DependencyProperties verwendet, hätte man ja auch einen Self-Scope machen können:
<TextBlock Text="Item" Self.Font.FontStyle="Italic" />
Dies hätte man auch in der Vererbungshierarchie prima implementieren können.

<Element Property="wert" /> << normales Property
<Element Class.Property="wert" /> << Attached Property
<Element Namespace:Class.Property="wert" /> << Eigenes attached Property
So ist nunmal die Syntax, wenn nun auch eingebaute Properties über . erreichbar sind, kann es sehr böse Seiteneffekte geben.

PS. Du kannst "TextBlock" auch so verwenden, die Properties gibt es als attached:

<StackPanel TextBlock.FontStyle="Italic">
    <TextBlock Text="Item" TextBlock.FontStyle="Normal" />
    <TextBlock Text="Item" TextBlock.FontSize="13" />
</StackPanel>

Ichj finde FontStyle="Italic" oder FontWeight="Bold" als normale Properties stören nicht. Die verwendung ist dann konsistent und oft setzt man sowieso nur eines oder Maximal 3.

(Wenn man "Font.Bla" sagen müsste würden alle über die inkonsistenz Weinen :D)

Dravere

David W schrieb:

Ich vermute das ist eine Milchmädchen rechnungen. Sie überlegen sich wieviele WPF einsetzen, und davon fragen gerade mal 2% nach -> Lohnt nicht. Dazu kommen ja noch Maintenance kosten wenn etwas nicht funktioniert oder geändert werden soll, auch das mit ziehen in den nächsten Versionen.

Toll, und wie willst du dann sonst die Erhebung machen, wer die wirklich will? Da hast du immerhin ein paar Daten, sonst hast du gar keine Daten und machst eine reine Vermutung.
Common Dialogs sind für Endkunden wahnsinnig wichtig. Gibt nichts schlimmeres als wenn jedes Programm für die Standarddialoge ein anderes Design einsetzt. Und vor allem wenn alle bereits an ein Design gewohnt sind, dass man sie bei WPF Anwendungen auf zig andere Implementierungen stossen lässt.

Und wenn sie es wirklich als zu aufwendig erachten, dann sollen sie angenehme und einfache Konverter einbauen. Dafür ist der Aufwand minim, aber sowas machen sie auch nicht. Bestes Beispiel ist da auch immer wieder Bitmap. Dort hätten sie ja auch einfach eine BitmapView oder sowas einbauen können, damit man zumindest die alten Bitmap-Klassen anzeigen kann. Aber naja ...

David W schrieb:

<Element Property="wert" /> << normales Property
<Element Class.Property="wert" /> << Attached Property
<Element Namespace:Class.Property="wert" /> << Eigenes attached Property
So ist nunmal die Syntax, wenn nun auch eingebaute Properties über . erreichbar sind, kann es sehr böse Seiteneffekte geben.

Ja, das ist mir schon klar, deswegen hätte man ja ein Schlüsselwort Self oder so reinbringen können. Möglich wäre es sicherlich gewesen. Das ist nur einer der Punkte, wo ich der Meinung bin, dass man zu früh aufgehört hat, das Design zu schleifen.

David W schrieb:

PS. Du kannst "TextBlock" auch so verwenden, die Properties gibt es als attached:
<StackPanel TextBlock.FontStyle="Italic">
    <TextBlock Text="Item" TextBlock.FontStyle="Normal" />
    <TextBlock Text="Item" TextBlock.FontSize="13" />
</StackPanel>

Ebenfalls klar, steht ja auch in jedem Anfängerbuch.

David W schrieb:

Ichj finde FontStyle="Italic" oder FontWeight="Bold" als normale Properties stören nicht. Die verwendung ist dann konsistent und oft setzt man sowieso nur eines oder Maximal 3.

In Xaml ist es wirklich nicht sonderlich schlimm. Mich stört es eher im Codebehind. Wenn man da eben Veränderungen durchführen muss, wird es mühsam. Und man kann eben nicht alles nach Xaml verschieben. Daher hätte man darauf achten müssen, dass es auf beiden Seiten angenehm in der Verwendung ist.

Grüssli

EXDW

Dravere schrieb:

David W schrieb:

Ich vermute das ist eine Milchmädchen rechnungen. Sie überlegen sich wieviele WPF einsetzen, und davon fragen gerade mal 2% nach -> Lohnt nicht. Dazu kommen ja noch Maintenance kosten wenn etwas nicht funktioniert oder geändert werden soll, auch das mit ziehen in den nächsten Versionen.

Toll, und wie willst du dann sonst die Erhebung machen, wer die wirklich will? Da hast du immerhin ein paar Daten, sonst hast du gar keine Daten und machst eine reine Vermutung.
Common Dialogs sind für Endkunden wahnsinnig wichtig. Gibt nichts schlimmeres als wenn jedes Programm für die Standarddialoge ein anderes Design einsetzt. Und vor allem wenn alle bereits an ein Design gewohnt sind, dass man sie bei WPF Anwendungen auf zig andere Implementierungen stossen lässt.

Und wenn sie es wirklich als zu aufwendig erachten, dann sollen sie angenehme und einfache Konverter einbauen. Dafür ist der Aufwand minim, aber sowas machen sie auch nicht. Bestes Beispiel ist da auch immer wieder Bitmap. Dort hätten sie ja auch einfach eine BitmapView oder sowas einbauen können, damit man zumindest die alten Bitmap-Klassen anzeigen kann. Aber naja ...

Ist eh alles nur eine mutmaßung, wir wissen beide nicht warum was wann raus kommt.
Ich erinnere mich, als letzten Dezember der Microsoft Mensch zwecks schulung bei uns war hatten wir auch gefragt was alles in .Net 5 und WPF 5 alles rein kommen wird. Er konnte es aber nicht sagen da er es selber nicht wusste, er bot nur an das er für uns nachfragt wenn wir ihn eine Mail schicken. Tat aber soweit ich weiß niemand

Dravere schrieb:

David W schrieb:

Ichj finde FontStyle="Italic" oder FontWeight="Bold" als normale Properties stören nicht. Die verwendung ist dann konsistent und oft setzt man sowieso nur eines oder Maximal 3.

In Xaml ist es wirklich nicht sonderlich schlimm. Mich stört es eher im Codebehind. Wenn man da eben Veränderungen durchführen muss, wird es mühsam. Und man kann eben nicht alles nach Xaml verschieben. Daher hätte man darauf achten müssen, dass es auf beiden Seiten angenehm in der Verwendung ist.

Ach du redest von der CodeBehind?
Ich sag mal so, ich kenne in meiner Firma kein WPF Entwickler der UI Elemente im CodeBehind erzeugt, nichtmal im Code von Custom Controls. Ich frage mich wann man soetwas braucht.
Und selbst wenn es so ist das man viele TextBlocks im Code erstellen muss, ist es auch nur einmalig, und falls es häufiger wird kann man sich eine ExtensionMethod schreiben die den Zugriff erleichtert (aber als erstes sein Lösungsweg überdenken ^^)

Dravere

David W schrieb:

Ach du redest von der CodeBehind?
Ich sag mal so, ich kenne in meiner Firma kein WPF Entwickler der UI Elemente im CodeBehind erzeugt, nichtmal im Code von Custom Controls. Ich frage mich wann man soetwas braucht.

Wenn man dem User die Möglichkeit geben möchte, Elemente auf einer Flächer selber anzuordnen. Zum Beispiel in einem Diagram-Designer oder sowas ähnliches. Dann musst du auf den User reagieren und nach dessen Vorgaben Elemente erzeugen und positionieren.

Grüssli