Discussion :

[Greuter]

Bonjour,

Je programme dupuis longtemps sur visual basic 6 sp2 et depuis déjà un petit
moment lors du débuggage, lorsque j'arrête l'exécution pas par pas en cliquant
sur le bouton "Stop" le complilateur se ferme complétement. Je n'ai plus qu'a le
rouvrir. Aucun message d'erreur n'est signaler pas Windows, il disparait sans laisser de traces apparentes. C'est assez difficile de faire de la maintenance dans ces conditions. J'ai eu ce problème sur deux ordis différents et après avoir
réinstaller visual basic 6 mais seulement avec un certain projet vb. Donc ce problème est lié au .vb.

Quelqu'un aurait une idée?

Merci de vos suggestions ou solutions magiques!

[jmfmarques]

mais seulement avec un certain projet vb

Il semble donc qu'il te faille te focaliser sur CE projet, dont on ne connaît ni le code ni le reste....

[Greuter]

jmfmarques,

Merci pour ta réponse et je pensais bien qu'il s'agissait du ce projet.
Il est très gros, une 30aine de formulaires et il est bien réalisé sans trop
de tièrce partie n'y de composants de connection aux bd.

Comme c'est quand même un plantage complet et sans erreurs ça me semble tout de même extraordinaire et particulier et je doute que cela provienne
du code mais plus d'une explosion de la mémoire, un truc de pro en info!
Car ce plantage est survenu après la finalisation du logiciel.

J'ai un autre projet encore plus gros et bien mal foutu qui ne provoque pas
cette erreur!

[jmfmarques]

Car ce plantage est survenu après la finalisation du logiciel.

1) De quel "logiciel" ? (tu voudrais dire ton "application" ?)
2) Qu'entends-tu par "finalisation" ?

[MGD_Software]

J'ai le même problème avec certains de mes projets.

Après analyse, il apparaît que les projets concernés utilisent TOUS un contrôle utilisateur de ma fabrication (une grille de saisie basée sur un controle MSFlexGrid). J'ai réétudié en détail ce contrôle, mais je n'ai relevé aucune erreur grossière. Il n'y a pas d'utilisation de l'API Windows (ce qui génére habituellement 80% des erreurs de ce type).

Le plus curieux est que le plantage sec intervient sous l'environnement de développement, mais qu'une fois compilée l'application fonctionne parfaitement.

Après réflexion, je pense que dans mon cas le problème est dû au traitement d'un évènement qui fournit en paramètre la propriété ".List" d'un contrôle listbox afin que l'appli utilisatrice du contrôle utilisateur remplisse cette liste. J'ai bien peur que si on ne remplit pas cette liste, on renvoie peut-être un pointeur invalide.

Le moteur de Windows sait traiter cette erreur (on obtient alors la fameuse "Cette application a provoqué une erreur et doit fermer"), mais il est possible que l'environnement de développement intercepte l'exception de windows sans la traiter. On a alors exactement le symptome observé.

Il faut donc rechercher du côté des contrôles ou DLL ActiveX utilisés, vérifier si ce projet est le seul à utiliser l'un d'entre eux, et se pencher sur le traitement de ses évènements.

Malheureusement, je ne peux pas certifier que sur ce projet, la cause soit la même que dans les miens. Pour info, le problème ne se posait pas avec le SP5 de VB6 (mon contrôle suspect existait déjà). Il faut donc peut-être aussi se pencher sur les contrôles mis à niveau par le SP6 (tiens, justement, MSFlexGrid !). Mais comme ils le sont presque tous...

[Greuter]

MGD_Software,

Merci pour la réponse! C'est tout à fait ça. Il y a avait une erreur dans mon premier message, j'ai le sp6...
Je comprends bien et en effet j'ai une ocx "maison" que je n'utilise que dans
ce projet vb. Donc je vais essayer de trouver l'événement qui pourrait
générer le plantage sec. J'ai aussi quelque API. Merci pour la piste.

Salutations