Lors de la création d'un IValueConverter personnalisé pour un champ modifiable par l'utilisateur, l'implémentation de conversion est généralement assez simple. L'implémentation de ConvertBack n'est pas, puisque (en l'absence d'une règle de validation explicite) il doit faire face à une mauvaise entrée de l'utilisateur (par exemple en tapant "hi" dans un champ de saisie numérique).Erreurs lors de la conversion de valeur
Si une erreur se produit lors de la conversion, il ne semble pas être un moyen de communiquer l'erreur spécifique:
- ConvertBack ne peut pas lancer des exceptions (si elle le fait, le programme se termine).
- Renvoyer une ValidationError ne fait rien.
- La restitution de DependencyProperty.UnsetValue (suggérée par les documents) entraîne une défaillance silencieuse (aucune erreur ne s'affiche à l'utilisateur, même si vous avez configuré un modèle d'erreur).
- La valeur non convertie d'origine provoque l'affichage de l'erreur UI, mais avec un texte d'erreur trompeur.
Est-ce que quelqu'un connaît une meilleure façon de gérer ce genre de chose?
(Note: tout en définissant une ValidationRule personnalisée fonctionnerait, je ne pense pas que ce soit une bonne réponse, car il aurait essentiellement dupliquer la logique de conversion pour découvrir l'erreur de toute façon.)
Je parle d'une situation où je don Cependant, je ne veux pas du tout définir une règle de validation. Mais oui, vous avez raison que vous pouvez éviter le problème par exemple. définir toutes les propriétés de l'utilisateur dans le ViewModel en tant que chaînes.Mais cela semble aussi un peu extrême, et * aussi * n'aide pas à montrer l'interface utilisateur d'erreur, du moins pas avec les mécanismes intégrés. – Miral
Vous évitez le problème? Pas du tout. Voir ma modification. La seule chose que l'approche que je dessine est la possibilité de définir le convertisseur de valeur sur l'objet de liaison. Je ne peux pas penser à une bonne raison d'attacher des convertisseurs de valeur aux liaisons si vous utilisez un ViewModel. –