WPF de Liaison de zone de texte avec mise en forme
J'ai juste mis à jour notre application wpf à partir de 3.5sp1 à 4.0.
Le code ci-dessous que nous utilisons pour lier la zone de texte sous-jacent au modèle de vue. La zone de texte est modifiable.
<TextBox HorizontalContentAlignment="Right"
Text="{Binding Path=Price, StringFormat={0:#,##0;(#,##0)}, Mode=TwoWay, ValidatesOnDataErrors=True, UpdateSourceTrigger=PropertyChanged, ValidatesOnExceptions=True}"/>
En 3.5sp1 la mise en forme ne pourrait se produire qu'au départ. Ainsi, lorsque la zone de texte a été chargé et lié à la valeur de 4000, la mise en forme allait changer à 4 000. Si l'utilisateur a modifié cette valeur aucune mise en forme n'aurait lieu.
Dans la version 4.0 de la mise en forme se produit comme la modification de la valeur (c'est à dire pendant que l'utilisateur entre dans une nouvelle valeur). Si, en théorie, cela semble OK, en réalité, son une catastrophe. Le curseur est tous sur la place. Ses inutilisable.
Maintenant, nous pourrions changer le UpdateSourceTrigger "LostFocus" mais qui introduit de nouveaux problèmes avec les données ne sont pas validées dans certains scénarios.
Est-il un moyen pour obtenir l'ancien 3.5sp1 comportement?
Mise à jour de 1
À l'aide de Convertisseur encore procudes même comportement:
public class DecimalConverter : IValueConverter
{
public object Convert(object value, Type targetType, object parameter, CultureInfo culture)
{
if (value != null)
return ((decimal)value).ToString("#,##0;(#,##0)");
return string.Empty;
}
public object ConvertBack(object value, Type targetType, object parameter, CultureInfo culture)
{
return value;
}
}
et de la modification de la XAML:
<TextBox Text="{Binding Path=Price, Converter={StaticResource DecimalConverter}, Mode=TwoWay, ValidatesOnDataErrors=True, UpdateSourceTrigger=PropertyChanged, ValidatesOnExceptions=True}"/>
Mise à jour 2
Similaire à ce connectez l'article.
Oui Jonathan, j'ai commencé à regarder LostFocus, mais a été dans l'espoir d'éviter un énorme changement global. 🙁
OriginalL'auteur ozczecho | 2011-01-04
Vous devez vous connecter pour publier un commentaire.
Comme une mise à jour, j'ai pris Jonathans suggestion et reproduite à la Liaison à utiliser LostFocus au lieu de PropertyChanged (le cas échéant - c'est à dire partout où StringFormat a également été précisé).
Que Jonathan a dit, dans certains cas, vous devez déclencher de liaison de rafraîchissement /validation manuelle de cette approche.
Si quelqu'un a une meilleure approche, j'aimerais le voir.
OriginalL'auteur ozczecho
Je n'étais pas satisfait de la LostFocus solution, j'ai donc décidé de code d'une méthode qui déplace manuellement le curseur correctement. Je l'ai mis dans le fichier code-behind et en l'ajoutant à l'événement TextChanged sur la zone de texte il le faire fonctionner à chaque fois que la modification du texte.
Il suffit d'ajouter ce pour l'événement TextChanged comme suit:
Je ne suis pas sûr à 100%, mais cela semble bien se comporter, mais il ne gère pas la suppression de séparateur de milliers.
MODIFIER: j'ai compris comment gérer le séparateur de milliers. J'ai fait une autre méthode dans le fichier code-behind, et le mettre sur le PreviewKeyDown événement sur la zone de texte. Cette méthode vérifie si la zone de texte est la réception d'un retour arrière de Supprimer le bouton d'entrée, et l'ignore et déplace le curseur à la place.
Avis le cas particulier d'un séparateur de milliers dans le premier char dans la zone de texte, où il est supprimé au lieu de sauté. Un séparateur de milliers, idéalement, devrait ne jamais être là, mais le n0 numéro de formateur ne gère pas le cas où vous supprimez les premiers numéros avant le premier séparateur de milliers.
OriginalL'auteur Sammi
Vous pouvez essayer d'enlever
StringFormat={0:#,##0;(#,##0)}
et écrire convertisseur pour faire le formatage.vous ne pouvez rien faire sur convertback fonction de convertisseur
Je pensais aller en bas de la route du Convertisseur mais je voulais vérifier s'il y avait une autre façon. Après votre réponse, j'ai décidé de lui donner un aller, mais le comportement est le même (voir la mise à jour 1).
OriginalL'auteur Arsen Mkrtchyan