Discussion :

[noftal]

Bonjour,

dans un datgriview ouvert en écriture, dont le datasource est un bindingsource rattaché à une table de BdD SQLite, je peux être amené à modifier des valeurs.
Lorsque je quitte une cellule après avoir renseigné une donnée, j'ai un message d'erreur qui s'affiche (voir ci-joint) dont je n'arrive pas à trouver l'origine même en mode debug pas à pas.

La pertinence de ce message est bonne (l'erreur se déclenche dès que le type de donnée saisie dans le DTG n'est pas compatible avec le champ de BdD sous-jacent) mais je suis surpris que le DTG intercepte à validation de chaque cellule si le type de donnée est compatible avec celui du champ sous-jacent dans la table. Sachant que je n'ai écrit aucun code sur simple fait de quitter une cellule après modification. D'ailleurs, je n'ai pas encore rédigé la partie de code qui consiste à mettre à jour al table avec la valeur saisie dans une cellule.

D'autre part, le message est quand même assez abscons. J'aurais préféré le personnaliser par mon propre message du type "donnée invalide", mais comme je n'arrive pas à savoir ce qui déclenche ce message, je suis encore moins en mesure de le bypasser par une routine de traitement d'erreur. D'autant que j'ai déjà une routine d'erreur qui teste la validité de tous les champs d'une même ligne de DTG modifiée, à validation de cette ligne dans sa globalité.

Quelqu'un peut-il m'aide ?

[callo]

Pour personnaliser le message d'erreur, tu peux te servir de l'event CellValidating.

[noftal]

C'est à peu près ce que j'ai prévu de faire mais au niveau de la ligne globalement avec RowValidating.
Peu m'importe que l'utilisateur saisisse des données folkloriques tant que le processus de validation de l'enregistrement ne démarre pas.
A ce moment là ma procédure vérifie la validité de tous les champs de la ligne en cours et affiche des messages ciblés.
Le DTG n'est qu'un affichage de tableau. Tant qu'on ne lui demande pas de traiter une donnée saisie (pour mettre à jour la datatable ou la BdD), je pensais qu'il n'en faisait rien, a fortiori cellule par cellule sur une ligne donnée.

[_Ez3kiel]

Le DGV type ses colonnes selon la source qui lui est fourni, si tu le remplis avec une DataTable qui pioche sur une table BDD avec par exemple un champs numérique, il transposera ce typage sur le DGV.

Soit tu t'y conformes et fais tes tests pour chaque cellule (au final ce sera presque le même algo que pour la ligne entière) où dans l'event CellValidating, tu diffère ton algo selon le sender (la celulle qui appelle l'event), et ensuite tu appliques ton test. (Ce qui revient sensiblement au même que de tester chaque cellule individuellement au RowValidating)

Soit tu peux redéfinir manuellement le typage des colonnes de ton DGV pour mettre tout en String, ainsi tu n'auras plus de messages de CastException et tu pourrais tester tes cellules en les "Castant/Ctypant" dans ton event RowValidating.

[noftal]

D'accord, donc si je comprends bien, à partir du moment où ma BdD a des champs typés je n'ai pas d'autre choix que de contrôler le type, cellule saisie par cellule saisie et ne peux donc pas différer ce contrôle au niveau de la ligne globale ?

[_Ez3kiel]

Ou peut-être qu'un e.Handled = True sur l'event DataError outrepasserai ton message d'erreur, mais je ne suis pas sûr que ce soit "jolijoli" ...


EDIT : Et si tu peux passer par RowValidating, mais pour ça tu risque de devoir passer tes colonnes de DGV en type String ... (Je pense, si des personnes plus à l'aise avec les DGV ont une autre solution, qu'ils n'hésitent pas à me contre-dire.)

[noftal]

[QUOTE=_Ez3kiel;7497518]Ou peut-être qu'un e.Handled = True sur l'event DataError outrepasserai ton message d'erreur, mais je ne suis pas sûr que ce soit "jolijoli" ...

e.handled n'est pas proposé pour ce type d'événement.
J'avais essayé e.cancel = true mais ça revient à bloquer le curseur sur le champ tant qu'on n'a pas saisi une valeur du bon type.

Je pense que je vais répartir mon contrôle de saisie en 2 parties :
- sur l'event DataError du DTG : contrôle de la validité du type de donnée saisie, se résumant à l'instruction e.handled=true. L'utilisateur devra comprendre tout seul que sa donnée n'est pas bonne. Je vais peut-être activer des tooltips pour l'aider...
- sur l'event RowValidating du DTG : pour s'assurer que les valeurs rentrées sont correctes indépendamment du type de donnée (par exemple, sur un champ, la valeur doit être différente supérieure à 0)

Merci de ton aide en tout cas.