Discussion :

[SER]

Bonjour

J'ai actuellement un soucis qui me rend chèvre depuis 2 jours.
J'espère que l'explication sera assez claire.

Je travaille sous Delphi 6.0 ( ttes les MAJ sont faites), Windows XP Pro mais j'ai fait des essais sous NT et sous 98, le soucis est le même.

Après moulte essais, j'ai fini par trouver le soucis dans mon appli et voici donc la version 'Light' qui ma permis de mettre à jour le problème

J'ai un programme qui ne fait rien ( juste une ouverture de form).
J'ai une DLL assez complexe mais que je ne l'appelle pas dans le programme ( juste un Uses de l'unité qui utilise la DLL).

Lorsque je compile le programme avec DELPHI, celui se plante lamentablement sur le END final ( à la fermeture de la form) en envoyant le message 'trop d''exceptions consécutives' (sic).

Lorsque je compile la DLL avec DELPHI et que j'y associe le programme, tout se passe bien et je n'ai pas d'erreur

Sans DELPHI, lorsque je lance le programme celui ci semble se terminer sans erreur mais je le retrouve dans la liste des process. Si je lance 10 fois le programme ( et que je ferme la fenêtre à chaque fois) je retrouve quand même les 10 instances dans la barre de tâche.

Lorsque je retire la clause USES, le programme fonctionne correctement.

Pour info :
- J'ai vérifié les options de compilation qui sont identiques entre la DLL et le programme.
- J'ai vérifié que je travaille bien avec une seule DLL et un seul programme.
- J'ai essayé de travailler avec la DLL en la laissant en STATIC ou en la changeant en Dynamic.

En désespoir de cause, j'ai réinstallé DELPHI et le résultat est .... le même.

Je ne pense pas que qqun me donne directement la solution ( cela serait génial) mais si vous aviez une piste cela m'aiderait beaucoup.

Merci par avance.. J'y retourne.

[rv66]

moi quand je ne trouve pas, surtout des anomalies bizarres. Je procede de la maniere suivante :
j'enleve des bouts de code jusqu'à ce ça ne plante plus. C'est efficace est rapide.
et quand ça remarche, je procede dans l'autre sens pour trouver le coupable.

Evidement, il faut le sauvegarder avant.

bon courage
rv

[djo.mos]

tu ne peux pas nous filer un peu de code de l'unite qui importe la DLL ?

[SER]

Depuis 2 jours je supprime des morceaux de code. Mon application va finir par ne plus contenir rien du tout et enfin, elle va marcher

Pour info, le code de la DLL est, je pense, tout simple et il est du type

Procedure GXP_MONITEUR_INIT; StdCall; External 'GXP_MONITEUR.DLL';

mais je n'utilise pas cette fontion dans mon programme de test. il suffit que je la mette en commentaire pour ne plus avoir de soucis....

Enfin, depuis tout à l'heure j'ai supprimé encore des morceaux et je m'apercois que le problème n'apparaît que si Delphi charge la DLL. S'il elle n'est pas chargée, pas de soucis ( Le chargement où non de cette DLL est d'ailleurs un peu bizarre, je ne sais pas si c'est DELPHI ou WINDOWS qui décide mais, une fois sur 2, avec le même code, la DLL est chargée ou non).

Bon, au vu de tout çà le problème semble venir de la DLL. Je vais donc faire des coupes sombres la dedans et essayer de trouver le coupable.

Le code étant assez long, je ne pense pas qu'il soit utile de le mettre sur ce message et il faudrait que j'explique beaucoup de choses pour que vous puissiez lire le code. Je vais donc chercher encore de mon coté ( quand on aime ...) et je mettrais une balize [RESOLU] lorsque j'aurais la solution.

Juste une question, transfuge de Turbo Pascal, j'aime beaucoup INITIALISATION et FINALIZATION, est-ce conseillé dans une DLL où cela peut-il me créer des soucis ?

PS : Merci aux personnes qui m'ont répondu si rapidement.

[djo.mos]

normalement, il n'y a rien contre initialization et finalization !

[rv66]

plutot de mettre
Procedure GXP_MONITEUR_INIT; StdCall; External 'GXP_MONITEUR.DLL'
remplace par
Procedure GXP_MONITEUR_INIT; StdCall;
et monte la en dynamique. ça évitera à delphi de charger la DLL
loadlibray + GetProcAddress : le fonctionnement est le même.

[Reisubar]

J'ai eu ce problème avec une DLL, une fois... Ta DLL contient elle des composants graphiques (forms) ? As tu vérifié toutes les clauses initialization et finalization des unités composant ta DLL, sont-ils encadrés de try...except ? As tu testé de déboguer ta DLL avec ton appli (déboguage distant) ?

[SER]

Résolu. Enfin

Après avoir supprimé quasiment tout, j'avais toujours le pbme.
J'ai donc décidé de travailler à l'envers. De partir d'un exemple vierge et de rajouter les élèments que j'avais développé jusqu'à ce que le problème apparaisse.

Au bout d'un moment, j'ai eu un message d'erreur, différent de celui qui me posait, des problèmes, mais bon.... J'ai creusé cette piste.

J'ai fini par trouvé une fichier DCU qui trainaît ( ) sur 2 répertoires de mon PC.
Pour info, cette unité contient des routines de base que j'utilise un peu partout et que j'ai gardé de coté ( formattage, recherche de chaine de caractère, .....).

J'ai donc supprimé une des deux DCU et recompilé l'ensemble. La version LIGHT fonctionne maintenant correctement. Il me reste à retirer mes commentaires et à refaire tourner l'application.... Avec un peu de chance

Pour conclure :
- La prochaine fois, je regarderai bien si il n'y a pas un fichier DCU qui traine avant de m'arracher les cheveux.
- Les messages d'erreur de Delphi 6.0 ne sont pas toujours très explicite pour retrouver les problèmes ( j'ai déjà eu le cas 2 ou 3 fois). Je ne sais pas s'il ya eu des améliorations sur les nouvelles versions de DELPHI mais, s'il y en a eu, je courre me mettre à jour.

Merci encore.

Pour info, cette DLL effectue toute l'interface HardWare de mon appli avec les <> matériels connectés ( Informatique Industrielle). Elle est donc toujours utilisée. J'avais lu que, dans ce cas, il fallait mieux laisser les procédures en STATIC ?