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.