Warum werden im UI Zahlen in den Input-Boxen immer unterschiedlich dargestellt?
Hallo zusammen,
in einer WPF Anwendung habe ich ein Problem, dass ich auf Teufel komm raus nicht lösen kann.
Im Projekt sind diverse per StringFormat formatierte Textboxen vorhanden (P, C2, N2 etc).
Diese Boxen lassen sich allerdings zur Runtime nicht gescheit bearbeiten.
Wenn man eine Zahl einträgt, dann muss man meistens das Komma für die Nachkommastellen löschen damit man da was Eintragen kann. Oder wenn man sag ich mal 5,12 einträgt, dann wird aus dem "default" ein 5,12,00. Es ist schwierig zu beschreiben 😦.
Das Binding kommt vom ViewModel und die gebundenen Properties sind vom typ float oder double.
Habt ihr das Problem schon mal gehabt? Die BindingModes sind TwoWay und als UpdateSourceTrigger ist PropertyChanged festgelegt.
Stelle ich den BindingMode auf OneWayToSource geht das zwar, aber dann geht mir die Formatierung flöten.
.....an unhandled exception is the first way to think about your pattern of programming....
.....nur weil ich nicht weiß was dort passiert, bedeutet es nicht, dass ich nicht weiß, wie man es lösen kann - aber das ist wahrscheinlich....
Suchst Du evtl. eine Masked TextBox?
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
Nach Möglichkeit nicht 😉.
Worin liegt denn der Sinn einer Formatierung wenn die Bearbeitung danach Murks ist 😄.
Wäre denn eine MaskedTextBox sinnvoller als eine Formatierung per XAML?
Ich hab es bisher bei kleineren Projekten so gelöst, dass ich das Property was dahinter liegt als String gesetzt habe und dann geparst habe.
Das wollte ich jetzt allerdings vermeiden.
Das wäre ein Beispiel
<TextBox x:Name="txtDiscount" HorizontalAlignment="Left" VerticalAlignment="Top" Margin="150,13,0,0" Width="200" Text="{Binding Path=Discount, Mode=OneWayToSource, UpdateSourceTrigger=PropertyChanged, StringFormat=P2}" TextAlignment="Right"/>
.....an unhandled exception is the first way to think about your pattern of programming....
.....nur weil ich nicht weiß was dort passiert, bedeutet es nicht, dass ich nicht weiß, wie man es lösen kann - aber das ist wahrscheinlich....
Die formatierten Textboxen sind ja im Grunde "MaskedTextBoxen".
Das einfachste wäre, die Formatierung zu löschen. Wenn die gebundene Eigenschaft vom Typ double oder int ist, dann kann man eh nichts falsches dort eingeben. Noch komfortabler wäre, ein fertiges Steuerelement zu verwenden, wie z.B. DoubleUpDown bzw. IntegerUpDown aus dem WPF Toolkit.
Weeks of programming can save you hours of planning
Das Problem wird hier wohl Dein UpdateTrigger sein: mit jedem Edit wird eben das Format ausführt.
Wäre es Dir lieber, wenn der User fertig ist? Dann musst Du den UpdateSourceTrigger auf LostFocus setzen.
- performance is a feature -
Microsoft MVP - @Website - @AzureStuttgart - github.com/BenjaminAbt - Sustainable Code
@Abt:
Nice - das klappt. Dann muss ich die Berechnung im Hintergrund nur ändern.
Aber - warum ist das so? Ich mein, es wäre doch schöner, wenn man die Formatierung setzen kann und diese auch genauso wie man es sich denkt (haha) bearbeiten kann...
@MrSparkle: Naja es ist halt schöner den Nutzern anzuzeigen welche Art von Wert gerade verlangt wird - sprich Prozent, Währung, normale Zahl etc.
Könnte alternativ auch ein Label dahinter setzen aber warum? Wenn es denn die Formatierung hergibt? Das irritiert mich halt ein bisschen.
Danke aber auch für deine Antwort.
Euer Forum / die Beiträge haben mir schon oft geholfen - vielen Dank dafür!
.....an unhandled exception is the first way to think about your pattern of programming....
.....nur weil ich nicht weiß was dort passiert, bedeutet es nicht, dass ich nicht weiß, wie man es lösen kann - aber das ist wahrscheinlich....
Warum wunderst du dich? Du verwendest als Binding Trigger PropertyChanged: nach jedem Tastendruck auswerten.
Also nimm einen anderen UpdateSourceTrigger-Typen oder eine TextBox die für solche Angaben erschaffen wurde.