J'ai une variable Privée et Globale dans toute ma classe.
Lorsque le code de l'une des sub se déroule cette variable est remis à True
alors qu'elle est initialisée à False !!
J'ai rajouté après chaques instructions la remise à false, mais la variable
ne veux rien savoir .. elle se remet fatalement à True ...
Dans aucunes de mes autres procédures je n'ai une remise à True de cette
variable ...
"Patrick Philippot" a écrit dans le message de news: %23E7d2Vi$
Patrick Philippot wrote:
A vu de nez et sans code ce n'est pas simple mais a priori je regarderai dans la direction suivante:
Oh bon sang, c'est l'heure de la sieste...
A vue de nez et sans code ce n'est pas simple mais a priori je regarderais dans la direction suivante:
Désolé.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AlexC
Je ne peux pas faire de pas à pas car le Pc de développement ne poosède pas les cartes PCI utilisées pas le PC. J'ai juste un système de "traces", qui m'indique par ou passe le programme. ce n'est pas si simple. Mais je viens de tomber sur la cerise ... apparemment c'étati un problème au niveau de la taille d'un tableau, car dans la doc de l'API il est dit que le premier index est 1 alors qu'en Vb c'est 0 .. je passait donc en paramètre un tableau trop grand, ce qui faisait que le dernier élément du tableau écrasait la valeur de ma variable ... Par contre ce que je n'arrives pas à saisir c'est pourquoi était-ce toujours la même varible qui était affecté ?? l'emplacement du tableau dans la mémoire n'est jamais le meme ! si ?
"Patrick Philippot" a écrit dans le message de news: OkbxW4h$
AlexC wrote:
Disons que ce comportement n'est apparu après que j'ai "trifouillé" aux APIs ....
A vu de nez et sans code ce n'est pas simple mais a priori je regarderai dans la direction suivante:
Quand on exécute des APIs Win32, on est en mode non managé. Donc une mauvaise utilisation de l'API qui provoquerait des modifications sur la pile ou en mémoire ne sera pas détectée. Et a priori, quand une variable change de valeur "toute seule" , c'est le genre de problème qui vient tout de suite à l'esprit.
Par ailleurs, pourquoi n'utilisez vous pas un breakpoint conditionnel qui surveillerait la variable en question et arrêterait le programme dès que sa valeur change? C'est fait pour cela après tout.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Je ne peux pas faire de pas à pas car le Pc de développement ne poosède pas
les cartes PCI utilisées pas le PC.
J'ai juste un système de "traces", qui m'indique par ou passe le programme.
ce n'est pas si simple.
Mais je viens de tomber sur la cerise ... apparemment c'étati un problème au
niveau de la taille d'un tableau, car dans la doc de l'API il est dit que le
premier index est 1 alors qu'en Vb c'est 0 .. je passait donc en paramètre
un tableau trop grand, ce qui faisait que le dernier élément du tableau
écrasait la valeur de ma variable ...
Par contre ce que je n'arrives pas à saisir c'est pourquoi était-ce toujours
la même varible qui était affecté ?? l'emplacement du tableau dans la
mémoire n'est jamais le meme ! si ?
"Patrick Philippot" <patrick.philippot@mainsoft.xx.fr> a écrit dans le
message de news: OkbxW4h$EHA.1188@tk2msftngp13.phx.gbl...
AlexC wrote:
Disons que ce comportement n'est apparu après que j'ai "trifouillé"
aux APIs ....
A vu de nez et sans code ce n'est pas simple mais a priori je regarderai
dans la direction suivante:
Quand on exécute des APIs Win32, on est en mode non managé. Donc une
mauvaise utilisation de l'API qui provoquerait des modifications sur la
pile ou en mémoire ne sera pas détectée. Et a priori, quand une variable
change de valeur "toute seule" , c'est le genre de problème qui vient tout
de suite à l'esprit.
Par ailleurs, pourquoi n'utilisez vous pas un breakpoint conditionnel qui
surveillerait la variable en question et arrêterait le programme dès que
sa valeur change? C'est fait pour cela après tout.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Je ne peux pas faire de pas à pas car le Pc de développement ne poosède pas les cartes PCI utilisées pas le PC. J'ai juste un système de "traces", qui m'indique par ou passe le programme. ce n'est pas si simple. Mais je viens de tomber sur la cerise ... apparemment c'étati un problème au niveau de la taille d'un tableau, car dans la doc de l'API il est dit que le premier index est 1 alors qu'en Vb c'est 0 .. je passait donc en paramètre un tableau trop grand, ce qui faisait que le dernier élément du tableau écrasait la valeur de ma variable ... Par contre ce que je n'arrives pas à saisir c'est pourquoi était-ce toujours la même varible qui était affecté ?? l'emplacement du tableau dans la mémoire n'est jamais le meme ! si ?
"Patrick Philippot" a écrit dans le message de news: OkbxW4h$
AlexC wrote:
Disons que ce comportement n'est apparu après que j'ai "trifouillé" aux APIs ....
A vu de nez et sans code ce n'est pas simple mais a priori je regarderai dans la direction suivante:
Quand on exécute des APIs Win32, on est en mode non managé. Donc une mauvaise utilisation de l'API qui provoquerait des modifications sur la pile ou en mémoire ne sera pas détectée. Et a priori, quand une variable change de valeur "toute seule" , c'est le genre de problème qui vient tout de suite à l'esprit.
Par ailleurs, pourquoi n'utilisez vous pas un breakpoint conditionnel qui surveillerait la variable en question et arrêterait le programme dès que sa valeur change? C'est fait pour cela après tout.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
Patrick Philippot
AlexC wrote:
Je ne peux pas faire de pas à pas
Justement, un breakpoint de type "Data change" évite d'avoir à faire du pas à pas. Le programme s'arrête tout seul quand la donnée surveillée est modifiée. Cela ralentit bien sûr considérablement la vitesse d'exécution.
Mais je viens de tomber sur la cerise ... apparemment c'étati un problème au niveau de la taille d'un tableau, car dans la doc de l'API il est dit que le premier index est 1 alors qu'en Vb c'est 0 .. je passait donc en paramètre un tableau trop grand, ce qui faisait que le dernier élément du tableau écrasait la valeur de ma variable
Ah, je me disais bien :-)
Par contre ce que je n'arrives pas à saisir c'est pourquoi était-ce toujours la même varible qui était affecté ?? l'emplacement du tableau dans la mémoire n'est jamais le meme ! si ?
Si rien ne change par ailleurs, il y a des chances que d'un run à l'autre l'organisation des données en mémoire reste la même. Ça ne me surprend pas trop. Même si les adresses physiques changent, l'adresse virtuelle dans l'espace adresse a des chances de rester identique. Il n'y a qu'à vérifier sur l'adresse de quelques variables avec le débogueur d'un run sur l'autre, c'est souvent la même chose.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
AlexC wrote:
Je ne peux pas faire de pas à pas
Justement, un breakpoint de type "Data change" évite d'avoir à faire du
pas à pas. Le programme s'arrête tout seul quand la donnée surveillée
est modifiée. Cela ralentit bien sûr considérablement la vitesse
d'exécution.
Mais je viens de tomber sur la cerise ... apparemment c'étati un
problème au niveau de la taille d'un tableau, car dans la doc de
l'API il est dit que le premier index est 1 alors qu'en Vb c'est 0 ..
je passait donc en paramètre un tableau trop grand, ce qui faisait
que le dernier élément du tableau écrasait la valeur de ma variable
Ah, je me disais bien :-)
Par contre ce que je n'arrives pas à saisir c'est pourquoi était-ce
toujours la même varible qui était affecté ?? l'emplacement du
tableau dans la mémoire n'est jamais le meme ! si ?
Si rien ne change par ailleurs, il y a des chances que d'un run à
l'autre l'organisation des données en mémoire reste la même. Ça ne me
surprend pas trop. Même si les adresses physiques changent, l'adresse
virtuelle dans l'espace adresse a des chances de rester identique. Il
n'y a qu'à vérifier sur l'adresse de quelques variables avec le
débogueur d'un run sur l'autre, c'est souvent la même chose.
--
Patrick Philippot - Microsoft MVP
MainSoft Consulting Services
www.mainsoft.fr
Justement, un breakpoint de type "Data change" évite d'avoir à faire du pas à pas. Le programme s'arrête tout seul quand la donnée surveillée est modifiée. Cela ralentit bien sûr considérablement la vitesse d'exécution.
Mais je viens de tomber sur la cerise ... apparemment c'étati un problème au niveau de la taille d'un tableau, car dans la doc de l'API il est dit que le premier index est 1 alors qu'en Vb c'est 0 .. je passait donc en paramètre un tableau trop grand, ce qui faisait que le dernier élément du tableau écrasait la valeur de ma variable
Ah, je me disais bien :-)
Par contre ce que je n'arrives pas à saisir c'est pourquoi était-ce toujours la même varible qui était affecté ?? l'emplacement du tableau dans la mémoire n'est jamais le meme ! si ?
Si rien ne change par ailleurs, il y a des chances que d'un run à l'autre l'organisation des données en mémoire reste la même. Ça ne me surprend pas trop. Même si les adresses physiques changent, l'adresse virtuelle dans l'espace adresse a des chances de rester identique. Il n'y a qu'à vérifier sur l'adresse de quelques variables avec le débogueur d'un run sur l'autre, c'est souvent la même chose.
-- Patrick Philippot - Microsoft MVP MainSoft Consulting Services www.mainsoft.fr
