Discussion :

[BasicZX81]

Bonsoir à tous, J'espère être sur bonne section du Forum. Je voudrais signaler certains problèmes et vous faire part de ma propre expérience concernant la programmation évènementielle en VB.NET. Je ne vous cache pas que certains petits détails m'ont exaspérés et je pense que ça méritait un petit post.
Donc par définition, en programmation évènementiel, on exécute du code dans des procédures évènementielles dont l'ordre chronologique et le moment ou sont levés ces évènements sont définies par le FrameWork et il faut faire avec. Ça serait parfait si Microsoft avait assuré une certaine cohérence entre les évènements des différents contrôles de saisies.

Je vous donne un exemple :
J'ai besoin de lire la valeur d'un TextBox quand l'utilisateur entre une nouvelle valeur : Je peux le faire dans TextBox.KeyUp. Et si on veux faire la même chose avec un DateTimePeacker, on pourrait penser à utiliser Keyup de la même façon mais en fait ça ne fonctionne pas, la valeur retournée par le DateTimePeaker étant l'ancienne valeur et non la nouvelle valeur entrée et donc en fait on s'appercoie qu'il n'y a pas d'équivalent de l’évènement KeyUp pour ce contrôle qui se comporte rigoureusement de la même façon. Ce n'est qu'un exemple mais je ne compte plus le nombre de mésaventure à cause de ces évènements complètement farfelus, je trouve ça aberrant.

Autre exemple avec des contrôles DataBindés et en gérant soit même l'écriture dans la base avec DataSourceUpdateMode.Never et un MyBinding.Writevalue :
Si on fait un WriteValue dans l'evénement CheckBox.Click ça fonctionne, on écrit bien la nouvelle valeur dans la base, en revanche si on fait la même chose avec un autre controle (MyTextBox.KeyUp ou MyComboBox.SelectionChangeCommitted, je sais plus lequel) on écrit l'ancienne valeur. Notez que j'ai choisi ces évènements car ils ne sont pas levés sur une modification qui provient du code mais uniquement par l'utilisateur (de toute façon j'avais noté aussi ce genre de problème avec d'autres évènements plus courant). je suis un peu imprécis et pas assez exhaustifs car j'écrits de mémoire mais les problèmes que j'ai rencontré à cause de ces évènements sont bien réel et dans bien des cas il n'existe pas l'évènements que l'on souhaiterez. L’évènement étant levé soit trop tôt ou soit trop tard selon le contrôle en question.
(Et je ne parle pas de l'annulation de la valeurs des contrôles DataBindés avec CancelEdit que le moteur de DataBinding ignore complètement).

[Pol63]

ce n'est pas parce que tu as des problèmes de compréhension ou de modélisation qu'il faut en déduire que le framework est nul
quand on l'utilise comme il doit l'être il n'y a pas de soucis

keyup pour savoir que le texte d'un textbox est modifié par exemple n'est vraiment pas adapté ! si l'utilisateur fait clic droit / coller le texte va changer et tu ne seras pas averti
c'est pour ca qu'il y a l'evenement TextChanged qui est prévu pour savoir ... quand le texte change
sur le datetimepicker il y a ValueChanged

donc le mieux serait peut etre que tu relises quelques tutos ...

[asmduty]

Je vais rejoindre Pol63.

Parfois effectivement on utilise un évènement inapproprié, mais ça ce n'est pas de la faute du Framework.

En faisant quelques recherches on comprend que l'on n'utilisait pas l'évènement qu'il fallait, en en règle général on trouve celui qu'il faut utiliser à la place.

Plutôt que de poster ce genre de message sur un coup de tête, tu ferais mieux de venir demander de l'aide, et on t'apportera probablement l'aide dont tu as besoin sur ce forum.

[BasicZX81]

Bonsoir, je ne réponds que maintenant à cause d'une coupure réseau. Je n'ai pas dit que le FrameWork était nul, j'ai terminé un programme assez conséquent pour mon niveau et j'en suis très satisfait, je trouve même énormément d'évolution dans VB.NET qui vont dans le bon sens. Mais ce n'est pas le but de mon post, je réagi juste sur l’évènement KeyUp. j'avais précisé que j'ai choisi cet évènement car il n'est pas levé par le code mais uniquement par une saisie utilisateur contrairement à TextChanged (malgré qu'il ne réagisse pas sur un copier coller). Alors c'est vrai que ça mérite une petite explication et je préfère vous soumettre la raison précise de mon choix, peut-être aurait vous un avis ou une technique à me proposer :

J'ai des contrôles de saisies utilisateurs DataBindés sur une base de données, ce qui signifie que si je parcours les enregistrements, les contrôles vont se mettre à jour. A leur tour ces contrôles vont lever des évènements que je ne désirent pas (comme TextChanged par exemple). Je ne désire pas ces évènements pour 2 raisons, d'une part il ont déjà été calculés quand je parcours mes enregistrements et le parcours de ces enregistrements rend l'interface très peu fluide si je lance les calculs cette manière (si j'ai 20 contrôles DataBindés, ce sont 20 calculs qui sont lancés et si on multiplie par le nombre d'enregistrement ça fait beaucoup trop). Donc ces calculs ne s’exécute que si l'utilisateur change la valeur d'un des contrôles.

Si vous avez un avis ça m’intéresse beaucoup. En vous remerciant.

[Pol63]

quand on fait du databinding c'est pour se passer des évènements

le principe c'est que sur le lostfocus le binding va mettre à jour ta propriété, et c'est à ce moment que ta classe prend le relais (ou des bindingvalidator ou autre), il n'y a pas à gérer textchanged, keyup ou autre

et textchanged se déclenche bien quand on colle du texte, même à la souris

[BasicZX81]

Bonsoir, Pol63 et merci d'avoir pris le temps de me répondre.
C'est donc sur LostFocus que la propriété est mise à jour ! Ça explique peut-être que je n'arrivais pas à récupérer la valeur proposé, je m'obstinais à vouloir récupérer cette valeur dès le click de souris pour un CheckBox ou TextChanged pour un TextBox. J'ai essayé 3 possibilitées pour récupérer cette valeur :
- en lisant la valeur proposed du DataRow à l'interieur de ColumnChanging
- en lisant la valeur Proposed du DataRow mais dans les évènements des contrôles cette fois ci.
- en lisant directement la valeur du contrôle Text ou Value dans les fameux évènements citées plus haut)

Tous ont été non concluant dans la mesure ou je n'obtenais jamais la valeur proposed ou modifié (ça fonctionné pour certains contrôles et pas pour d'autres ou encore ça fonctionné pour certains évènements et pas pour d'autres), d'ou la raison de mon premier post.
J'utilise 4 types différents de contrôles, le textBox, ComboBox, CheckBox et DateTimePeacker).
Le soucis peut provenir aussi du fait que je travaille directement sur des DataRow et que je n'utilise pas les classes que tu cite ? Et qu'est ce que les bindingvalidator ?
Il n'y a pas d'autres alternatives que LostFocus pour obtenir la valeur modifiée comme je le suggère plus haut ?
Désolé pour mon ignorance sur cette partie là. J'ai tout comme il faut, je gère parfaitement les accès aux données et l'ensemble de mon programme est très propre et très bien construit j'ai envie de dire mais cette partie de me pose quelques soucis. J'ai cherché désespérément un peu d'aide la dessus à plusieurs reprise.

[Pol63]

je ne suis pas spécialiste en bindings, surtout ceux de windows forms

par contre si tu utilises les évènements en plus du binding pour faire des calculs, il doit y avoir d'autres moyens de faire plus propre, et directement sur les datarow (plutot que de travailler avec les valeurs des controles)

[BasicZX81]

Bonjour, je suis entièrement d'accord. L'intérêt de faire du DataBinding est de pouvoir séparer l'interface utilisateur des couches métier et d’accès aux données.
Après il faut pouvoir intercepter les modifications utilisateurs, les évènements ColumnChanging et ColumnChanged sont tout indiqués pour faire ce type de traitement car il permettent notamment de récupérer la valeur "Proposed" du DataRow dès la modification de la propriété DataBindée. Mais car il y a un "mais", il faut pouvoir aussi annuler une modification utilisateur si cette modification ne respectent pas les contraintes et la logique de l'application sinon on peut se retrouver à écrire des données invalide. Pour cela voici ce que j'ai testé et mes constatations parmi ces 2 possibilités :
- On peux faire MonDataRow.CancelEdit, cela annule bien les modifications mais pas les contrôles qui conservent leur état d'avant l'annulation.
- On peux aussi lire la valeur "original" du DataRow et décider d'ecraser la valeur "Proposed" par celle-ci. Cela à le même effet que CancelEdit mais toujours pas d'annulation du contrôle.

Comme j'aime faire les choses proprement surtout quand il s'agit de présenter les données à l'utilisateur, je me suis un peu ennervé sur mon premier post et j'en suis désolé.
Mais vous l’aurais compris je n'ai toujours trouvé de solution satisfaisante et je ne demande qu'à comprendre.

[Pol63]

là aussi tu as raté un truc
à google : winforms binding validation
c'est ce qui permet de dire si la valeur saisie te convient ou non, si ce n'est pas le cas elle ne sera pas écrite dans ta source de donnée

j'ai surtout testé les binding wpf, mais je pense qu'on peut faire certains trucs sur winforms aussi, en wpf on peut au passage modifier l'interface pour expliquer à l'utilisateur ce qu'il doit saisir, mettre du route autour du controle etc...

[BasicZX81]

Merci beaucoup Pol63, j'ai trouvé un article sur msdn qui explique le principe de la validation de données. j'espère que je ne trompe pas mais le principe semble rester le même avec ou sans DataBinding sauf que avec le DataBinding on ne peux annuler que dans Validating. Dans Validated c'est trop tard, les données sont déjà écrites dans la source ou alors il faut changer la manière d'écrire dans la source avec DataSourceUpdateMode.Never et Control.DataBindings["<YOURFIELD>"].WriteValue

De plus l’évènement Validating se produit au moment ou le contrôle perd le focus. Comme je souhaite que la validation se produise immédiatement je vais tester les méthodes Validate et ValidateChildren pour forcer la validation sur les évènements appropriés de chaque contrôle. la encore j'espère que je ne dit pas de bêtises. Le temps de tester tous ça et je reviendrais très probablement donner mes résultats.

En tout cas je te remercie beaucoup, j'ai toujours un peu négligé ces principes de validation à tord, et dans le cas présent je retiens qu'il faut vraiment se conformer à ce qui est prévus par les développeurs du FrameWork et trop de libertés dans mon modèle et habitude de programmation mènent aux problèmes insolubles que j'ai rencontrés.
En même temps je ne cris pas encore victoire mais je pense et j'espère que ce devrait bien se passer.
Encore merci.

[Pol63]

dans validating tu peux faire cancel et le focus reste

[BasicZX81]

Merci pour la précisions Pol63, je vais encore vous solliciter, désolé mais c'est normal que mon contrôle garde la nouvelle valeur après e.cancel ?
Pour annuler définitivement il faut réecrire soit même la valeur originale dans le contrôle et comment faire ?
Il y a surement un truc qui m'échappe une nouvelle fois.

[BasicZX81]

J'ai trouvé pour relire la valeur originale :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

MonControle.DataBindings.Item(0).ReadValue()

[BasicZX81]

Je passe en résolu, ça fonctionne enfin correctement.
J'ai découvert au passage le composant errorProvider super génial même si il ne s'applique pas dans mon cas.
merci beaucoup vraiment , je suis super content depuis le temps que je tourne autour du problème. Quel bonheur quand ça fini par fonctionner ! .