[DataGridComboBoxColumn] bestimmte Einträge fett darstellen in Abhängigkeit der Zeichenlänge

Hi,

Ich habe folgendes Problem:

In einem DataGridComboBoxColumn will ich bestimmte Einträge mit fetter Schrift darstellen und zwar wenn die Länge des Eintrags der Spalte "Code" genau drei Zeichen lang ist.

<DataGridComboBoxColumn x:Name="DGC_ComboBox"
          DisplayMemberPath="Name"
          SelectedValuePath="Code"
          SelectedValueBinding="{Binding ID}" Width="250"/>

DGC_ComboBox.ItemsSource = dataView;

Kann mir jemand einen Tipp geben?

Gruß Maggo1404

Bin jetzt nicht der WPF Spezialist, aber eventuell helfen dir DataTrigger weiter, die den Style der Zelle anpassen? Könnte mir vorstellen dass du damit dein Problem löst.

Meine Lösung wäre dieses:

               <DataGridTemplateColumn>
                    <DataGridTemplateColumn.CellTemplate>
                        <DataTemplate>
                            <ComboBox ItemsSource="{Binding ComboItems}">
                                <ComboBox.ItemTemplate>
                                    <DataTemplate>
                                        <TextBlock Text="{Binding Path=Text}" FontWeight="{Binding Path=IsBold, Converter={StaticResource ResourceKey=FontConf}}"/>
                                    </DataTemplate>
                                </ComboBox.ItemTemplate>
                            </ComboBox>
                        </DataTemplate>
                    </DataGridTemplateColumn.CellTemplate>
                </DataGridTemplateColumn>

Hab ich schon in Verwendung.. ob das jetzt optimal ist, weiß ich allerdings nicht genau 😉

du solltest keinen zusätzlichen Konverter benötigen, wenn dein Viewmodel eh eine Property bereitstellt, um FontWeight zu definieren.
Nämlich dann kannste die Property so designen, dass sie gleich das gewünschte FontWeight angibt - so brauchste nix zu konvertieren.

Viewmodel heißt Viewmodel, weils ein Modell des Views ist.
Wenn dieses Modell auch Aussagen zur Fontweight machen soll - wieso sollte es sich dann dieses Datentypes enthalten?
Ein Viewmodel soll keine Controls enthalten, aber sone popelige Enumeration darf es schon kennen.

Und vor allem: Statt des Viewmodels muss dann ja der Konverter den Datentypen kennen - was also wäre gewonnen?

Und son Konverter tätigt immer Typ-Umwandlungen (meist sogar mehrere!), und jede Typ-Umwandlung setzt immer die Typ-Sicherheit punktuell ausser Kraft.
Code, der auf sowas verzichten kann ist von daher vom Prinzip her stark vorzuziehen.

Ich glaub, es war sogar Josh Smith höchstselbst (der Wpf-MVVM-Guru), der mal den Ausspruch tätigte, dass Converter insgesamt Unsinn seien, denn das Viewmodel selbst sei der Converter.
Nun, so weit geh ich nicht, aber als Denk-Anstoß...

Aber generell die Devise: Entweder Viewmodel oder Converter - nicht beides gleichzeitig.

Andernfalls ist der Aufbau vermutlich überverkompliziert, jdfs wenn man dann für jeden Piss einen Spezial-Konverter implementiert haben muss.

Hallöchen,

einen Konverter zu verwenden ist der richtigere Weg. Ui-Werte haben in einem Viewmodel eigentlich nix zu suchen, da man damit die Trennung von Oberfläche und Funktionaltität durchbricht.

Der Grund für eine Trennung von View und Model ist recht einfach erklärt : Testbarkeit. In einem Viewmodel definierst du, was mit Benutzerinteraktionen passieren sollen, also wie sich ein System durch eine Benutzereingabe verhält. Zb:

Du hast ein Eingabefeld, dass bei bestimmten Werten unterschiedliche Verhaltensweisen hat. Über einen Integrations/Unittest kannst du das Viewmodel testen ohne selbst einen Finger krumm zu machen. Dadurch ist es dir möglich, die funktionale Lauffähigkeit eines System zu stärken oder anders ausgedrückt, ein sichereres Gefühl bei Änderungen zu bekommen. Durch diese Tests ist, je nach Vollständigkeit, garantiert, dass du nicht ausversehen einen unerwünschten Seiteneffekt erzeugst.

Ich habe grundsätzlich alles im XAML was das GUI betrifft. Gerade solche Sachen wie Fonts, Farben, Sichtbarkeit und Größen lassen sich sehr gut über Trigger/Converter/Styles lösen. Denn das Resultat bei Komplexen ViewModels wäre:10 Methoden ändern 20 Properties die nur die UI betreffen und jeder gibt seinen Senf dazu. Das im späteren Projektverlauf bei neuen Anforderungen ohne irgendwelche unerwünschten Verhaltensweisen zu Ändern...dürfte spannend sein, also so gut wie unmöglich. Code wird nicht nur einmal geschrieben, sondern immer wieder angepasst und Fehler suchen ist ne unschöne Aufgabe, die Zeit kostet.

Am Ende ist es dir überlassen, wie du damit umgehst, 10 Leute ... 10 Meinungen.

vg

Testbarkeit Willst du damit sagen, eine Viewmodel-Property vom Typ FontWeight sei nicht testbar?
ist sie aber.

@Parso:

Der Grund für eine Trennung von View und Model ist recht einfach erklärt

Das ViewModel ist die Businesslogik des Views und sollte alles abdecken was der View benötigt, und wenn das eben ein Fontweight ist, dann ist das so.

View+VM == UI

Und wie ErfinderDesRades sagte, das kann man sehr wohl testen.

Und VM != Model

Das mag sein, aber mal ganz abgesehen davon dass ich nicht behauptet habe, dass man das nicht testen kann...macht es meines erachtens gar keinen Sinn nen Farbwert zu testen oder eine Schriftgröße oder sonst irgendwas in der Richtung. Soviel zu deiner kindisch provokanten Formulierung. Einmal ein Buch gelesen, schon ein Experte 😉

Mein Hauptargument war eher die Ausartung des Code, die sowas mit sich bringt. Ein schönes Beispiel wäre die Sichtbarkeit von Objekten, abhängig von bestimmten Zuständen deines ViewModels. Natürlich kannst du das in ein vm packen, aber ich finde es persönlich extrem nervig, Code zu warten, der über mehrere Funktionen verteilt einen UI-Wert setzt, das ist einfach schwer nachzuvollziehen. Hingegen bist du mit Triggern gezwungen, solche Zustände über Eigenschaften entsprechend zu ermitteln. Das ist wesentlich einfacher nachzuvollziehen und vor allem sauberer.

Ich weiß nicht wie stark deine Tests ausformuliert sind, aber ich würde nicht auf die Idee kommen, Farben oder Schriftgrößen zu testen, ich kenn ehrlich gesagt auch niemanden der das macht...mir ist die Funktionalität einer Anwendung wichtiger als das Aussehen.

Nicht immer arbeiten Entwickler und Designer im selben Büro, geschweige denn im selben Raum oder sind ein und dieselbe Person. Bei Miniprojekten von ein paar tausend Zeilen Code ist das alles noch überschaubar, das sieht bei 10 Leuten schon ganz anders aus.

Ein ViewModel ist natürlich auch ein Model...nur nicht für dein BL...daraus ergibt sich folgendes :
View+VM != UI weil View = UI...oder hat dein ViewModel n Knopf zum draufdrücken.

10 Leute ... 10 Meinungen ... und jeder weiß es besser als der andere...meine muss ja nicht richtig sein. also nen schönen tag noch.

Ich würd gerne ein stückweit zurücknehmen, dass ich generell abrate, hier einen Converter zu benützen.
Nämlich ich selbst würde evtl. hier einen verwenden, aber das liegt daran, dass ich einen generalisierbaren BoolConverter habe, der alles mögliche nach und von Bool konvertieren kann, und der könnte auch eine bool-Property IsBolded in eine FontWeight übersetzen. Vorteil im Code wäre, dass IsBolded ein klein bischen intuitiver zu erfassen ist, erkauft um den Nachteil, dass das Xaml bisserl länger würde - weil ich müsste ja mein Converter einfrickeln.
Aber wer den nicht hat, der müsste hier entweder mit einem Trigger vorfahren (was im Xaml ziemliches Gedöhns macht), oder eine extra Converter-Klasse erfinden (was im Datei-System viel Rauch um sogut wie nichts ist).

Also meine obige Devise muss ich ändern zu:

Ehe man selbst für so'n Kinkerlitzchen sich eine zusätzliche Klasse ins Projekt bastelt (u.a. mit den genannten Typumwandlungs-Risiken), ist wahrscheinlich vorzuziehen, dass das Viewmodel die FontWeight halt direkt angibt.

Wenn hingegen geeignete Converter bereitstehen, vergleichbares wie BooleanToVisibilityConverter - dann ist echt egal. Nur selbst einen Extra-BooleanToFontweightConverter schreiben wär mir zu blöd.

Hi Parso,

Soviel zu deiner kindisch provokanten Formulierung. Einmal ein Buch gelesen, schon ein Experte 😉

Laß es mich mal ganz deutlich sagen: Für solche Diskussionen ist das Forum der falsche Ort. Hier geht es um Software-Entwicklung, und wir erwarten von allen einen höflichen und respektvollen Umgang miteinander. Wenn du das nicht akzeptieren kannst, such dir bitte einen anderen Spielplatz.

Christian