Logo GNT
Actualités Tests & Guides Bons Plans
Twitter iPhone pliant OnePlus 11 PS5 Disney+ Orange Livebox Windows 11
Entraide Développement Développement Langage C Sharp Problème avec l'instruction DataTable dt.Rows.Clear

Problème avec l'instruction DataTable dt.Rows.Clear

10 réponses
Avatar
Oriane
Bonjour,

j'ai post=E9 r=E9cemment sur un probl=E8me de navigation. Vous serez =
heureux d'apprendre que j'ai progress=E9 sur ce terrain ! Mais cela ne =
r=E9soud pas mon probl=E8me, car je suis confront=E9 =E0 un comportement =
anormal du framework.

Dans certaines conditions - j'ignore lesquelles - cette commande =
effectu=E9e dans un callback ne s'effectue pas et me renvoie directement =
dans l'application (une Windows Form).=20

Je m'attendais =E0 tout le moins =E0 une exception...

A+
Signaler un problème avec ce contenu

10 réponses

Supprimer
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire

Veuillez sélectionner un problème

Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Avatar
Patrice
Continue dans le même fil de discussion STP que l'on ne se perde pas...

Ma première réaction serait d'afficher DataTable.dt.Rows.Count juste après
cette instruction. Cela permettrait de vérifier :
- que tu passes bien ici après cette instruction (tu sembles surprise de te
retrouver dans ton formulaire ?)
- qu'elle est bien exécutée

Attention aussi à la gestion des erreurs. Pendant le développement, je pense
qu'il est préférable de ne pas gérer du tout les erreurs pour voir des
exceptions plutôt que d'avoir un gestionnaire incomplet qui "avalerait" les
exceptions sans rien signaler...

Patrice
--

"Oriane" a écrit dans le message de
news:d1u2sv$vbi$
Bonjour,

j'ai posté récemment sur un problème de navigation. Vous serez heureux
d'apprendre que j'ai progressé sur ce terrain ! Mais cela ne résoud pas mon
problème, car je suis confronté à un comportement anormal du framework.

Dans certaines conditions - j'ignore lesquelles - cette commande effectuée
dans un callback ne s'effectue pas et me renvoie directement dans
l'application (une Windows Form).

Je m'attendais à tout le moins à une exception...

A+
Avatar
Oriane
Bonjour Patrice,

Tu n'es pas au Dev Days à Paris ;-) ?

J'ai l'impression en fait qu'il y a - peut-être - un sac de noeud entre deux event-handler.
En affichant la call stack, je me rends compte que le premier callback appelle le second à l'intérieur d'une instruction "Fill" qui remplit un dataset. Donc déjà si je ne mets pas un point d'arrêt sur ce second callback, je ne me rends même pas compte que j'y passe. Eh oui c'est sûr que c'est un inconvénient inévitable. Ceci dit je ne crois pas que cela soit à l'origine du problème.


"Patrice" a écrit dans le message de news: %
Continue dans le même fil de discussion STP que l'on ne se perde pas...

Ma première réaction serait d'afficher DataTable.dt.Rows.Count juste après
cette instruction. Cela permettrait de vérifier :
- que tu passes bien ici après cette instruction (tu sembles surprise de te
retrouver dans ton formulaire ?)


Je suis surpris de faire "NEXT" sur mon debugger VS.NET avant le "Clear" et de me retrouver sur mon appli, certes oui...

- qu'elle est bien exécutée


Justement dans certains cas elle ne l'est pas. Mais comme un callback est potentiellement appelé, va savoir...

Si je la commente tout marche impec par contre (je veux dire que évidemment je n'ai pas le comportement désiré, mais ca marche comme ca doit). Ce qui me fait dire que l'effacement des rangs alors même qu'un event-handler sur un "Select" est posé déclenche les problèmes.

Attention aussi à la gestion des erreurs. Pendant le développement, je pense
qu'il est préférable de ne pas gérer du tout les erreurs pour voir des
exceptions plutôt que d'avoir un gestionnaire incomplet qui "avalerait" les
exceptions sans rien signaler...


Ben en fait si j'ai une exception je la trappe au plus haut niveau et j'affiche le message dans une textBox.

A propos, j'ai repris un code de MS:

cmCmd = (CurrencyManager) BindingContext[ds1, "Commande"];

cmCmd.PositionChanged += new EventHandler(cmCmd_PositionChanged);

cmCmd_PositionChanged (this, null); // A QUOI CA SERT ??

Je ne sais pas ce que fais cette dernière ligne (que je n'ai pas incluse dans mon soft d'ailleurs).



A+
Avatar
Oriane
Finalement, en mettant un try /catch sur les callbacks, j'obtiens une exception!!!
Elle me dit que j'ouvre un second DataReader sans avoir fermer le premier, conséquence de l'enchainement des callbacks.

Bon à savoir.

"Oriane" a écrit dans le message de news: d1u2sv$vbi$
Bonjour,

j'ai posté récemment sur un problème de navigation. Vous serez heureux d'apprendre que j'ai progressé sur ce terrain ! Mais cela ne résoud pas mon problème, car je suis confronté à un comportement anormal du framework.

Dans certaines conditions - j'ignore lesquelles - cette commande effectuée dans un callback ne s'effectue pas et me renvoie directement dans l'application (une Windows Form).

Je m'attendais à tout le moins à une exception...

A+
Avatar
Patrice
Donc cela semble résolu ?

Cela vaut peut-être le coup de creuser aussi la raison pour laquelle un
try/catch local récupère l'erreur. A priori tu sembles avoir un try/catch
plus haut qui d'une façon ou d'une autre "masque" tes exceptions...


Patrice

--

"Oriane" a écrit dans le message de
news:d1u6at$121$
Finalement, en mettant un try /catch sur les callbacks, j'obtiens une
exception!!!
Elle me dit que j'ouvre un second DataReader sans avoir fermer le premier,
conséquence de l'enchainement des callbacks.

Bon à savoir.

"Oriane" a écrit dans le message de news:
d1u2sv$vbi$
Bonjour,

j'ai posté récemment sur un problème de navigation. Vous serez heureux
d'apprendre que j'ai progressé sur ce terrain ! Mais cela ne résoud pas mon
problème, car je suis confronté à un comportement anormal du framework.

Dans certaines conditions - j'ignore lesquelles - cette commande effectuée
dans un callback ne s'effectue pas et me renvoie directement dans
l'application (une Windows Form).

Je m'attendais à tout le moins à une exception...

A+
Avatar
Oriane
"Patrice" a écrit dans le message de news: %
Donc cela semble résolu ?


Je continue à m'arracher les cheveux avec les appels imbriqués des callbacks.


Cela vaut peut-être le coup de creuser aussi la raison pour laquelle un
try/catch local récupère l'erreur.


Sans doute...mais je ne suis pas un architecte théoricien MS

// A priori tu sembles avoir un try/catch
plus haut qui d'une façon ou d'une autre "masque" tes exceptions...


Ainsi par ex, le Rows.Clear () déclenche une exception lorsque des tables enfants pointent encore sur des rangs de la table parent qu'on efface... Je m'en suis aussi rendu compte après insertion du try/catch

Merci de ton aide ;-)
Avatar
Patrice
Pour le try/catch le principe serait simplement de voir dans les fonctions
appelantes si tu n'aurais pas un try/catch qui attrape une exception sans te
la signaler. En cas d'erreur c'est le premier try/catch en remontant les
appels qui gère le problème.

A mon avis c'est relativement important car sinon cela veut dire que tu peux
avoir des erreurs dans ton application qui ont toutes les chances de passer
inaperçue...

Bon courage.


--

"Oriane" a écrit dans le message de
news:d1uhe4$410$

"Patrice" a écrit dans le message de news:
%
Donc cela semble résolu ?


Je continue à m'arracher les cheveux avec les appels imbriqués des
callbacks.


Cela vaut peut-être le coup de creuser aussi la raison pour laquelle un
try/catch local récupère l'erreur.


Sans doute...mais je ne suis pas un architecte théoricien MS

// A priori tu sembles avoir un try/catch
plus haut qui d'une façon ou d'une autre "masque" tes exceptions...


Ainsi par ex, le Rows.Clear () déclenche une exception lorsque des tables
enfants pointent encore sur des rangs de la table parent qu'on efface... Je
m'en suis aussi rendu compte après insertion du try/catch

Merci de ton aide ;-)
Avatar
Oriane
Tous mes try/catch font la même chose: écrire le libellé de l'erreur dans la même textBox. Donc il est impossible que l'une d'elle passe à la trappe sans que je m'en apercoive.

Sur ce à lundi :-))

"Patrice" a écrit dans le message de news: %23Dy%
Pour le try/catch le principe serait simplement de voir dans les fonctions
appelantes si tu n'aurais pas un try/catch qui attrape une exception sans te
la signaler. En cas d'erreur c'est le premier try/catch en remontant les
appels qui gère le problème.

A mon avis c'est relativement important car sinon cela veut dire que tu peux
avoir des erreurs dans ton application qui ont toutes les chances de passer
inaperçue...

Bon courage.


--

"Oriane" a écrit dans le message de
news:d1uhe4$410$

"Patrice" a écrit dans le message de news:
%
Donc cela semble résolu ?


Je continue à m'arracher les cheveux avec les appels imbriqués des
callbacks.


Cela vaut peut-être le coup de creuser aussi la raison pour laquelle un
try/catch local récupère l'erreur.


Sans doute...mais je ne suis pas un architecte théoricien MS

// A priori tu sembles avoir un try/catch
plus haut qui d'une façon ou d'une autre "masque" tes exceptions...


Ainsi par ex, le Rows.Clear () déclenche une exception lorsque des tables
enfants pointent encore sur des rangs de la table parent qu'on efface... Je
m'en suis aussi rendu compte après insertion du try/catch

Merci de ton aide ;-)




Avatar
Ambassadeur Kosh
> Donc il est impossible que l'une d'elle passe à la trappe sans que je m'en
apercoive.



ça c'est ce que tu crois.
mais il n'en est rien...
Avatar
Paul Bacelar
"Ambassadeur Kosh" wrote in message
news:
> Donc il est impossible que l'une d'elle passe à la trappe sans que je


m'en
> apercoive.

ça c'est ce que tu crois.
mais il n'en est rien...






Pour compléter la réponse, les classes de la CLR se protèges souvent des
exceptions lors des appels de callback sur évènement.
Regarder le précédent post sur ce NG avec comme sujet "Exception non catchée
dans un drag/drop".
--
Paul Bacelar
Avatar
Oriane
Ah c'est dommage que tu confirmes (avec Paul) seulement maintenant ce que j'ai mis 2 jours à trouver :-((

"Ambassadeur Kosh" a écrit dans le message de news:
Donc il est impossible que l'une d'elle passe à la trappe sans que je m'en
apercoive.



ça c'est ce que tu crois.
mais il n'en est rien...