Discussion :

[maphi]

Slt,

Cette question s'adresse aux sp�cialistes de visual c++ 6.0 (le vieux)...
J'ai un workspace qui contient plusieurs projets (dll et exe).

Lors du debug d'un exe, je peux aussi debugger les dll attachees (je veux dire ke si je mets un bp dans le source d'une des dll il sera actif), jusque la, pas de pb.

Par contre, la plupart de mes exe lancent d'autres exe du projet (avec la fonction system()). Et la c'est l'echec : un bp dans le source d'un exe appell� est desactive par visual lorsque je lance la session de debug sur l'exe appelant.
Precision : tous les pdb sont dans le meme dossier et il y a vraiment bcp d'exe donc la solution de lancer un autre visual et d'attacher le process n'est pas vraiment envisageable.

La kestion est donc : est il possible de faire en sorte que tous les bps de tous les projets d'un workspace restent actifs ?

Question subsidiaire pour les pros de purify ce coup ci : de la m�me mani�re, y a t 'il moyen de purifier aussi les exe appeles depuis un autre exe ???

Thx

[farscape]

salut,
en dehors du fait qu'il est preferable d'utiliser shellexecute que systeme (
librairie C ) pour lancer un autre programme .
je ne pense pas que tu puisses continuer a debuger dans l'autre process.
et donc les breaks points ne suivent pas ...

[maphi]

Ok, thx pour le ShellExecute(), mais effectivement, ca ne r�gle pas mon pb...

[Aurelien.Regat-Barrel]

Tu peux essayer CreateProcess avec le flag DEBUG_PROCESS d�s fois que...
Sinon tu peux tenter de faire un _CrtDbgBreak ou assert(0) puis ignorer au d�but de ton WinMain pour forcer l'ouverture d'une nouvelle session de d�bogage sur l'exe lanc�.

[maphi]

Oui, le CreateProcess avec le flag DEBUG_PROCESS, ca ne me semble pas adapt� (d'apr�s ce que j'ai compris, il faudrait que je g�re les evts de debug dans mon prog appelant... a moins que ce ne soit possible de les rediriger vers visual)

Pour le assert, c'est une bonne id�e, merci. C'est pas exactement ce je voulais, mais c'est toujours mieux ke de lancer un visual et d'attacher le process a la main.
Seul pb, quand je debugge, il ne me mets pas les sources de mon prog... mais de l'assebleur (ca doit vaguement etre les sources de la msvcrt qu'il me fait debugger)
Enfin, je vais regarder ca de plus pres.

Thx.

[Aurelien.Regat-Barrel]

Ben en y r�fl�chissant, vu que tu as un projet par exe, �a me parrait difficile de d�boguer plusieurs projets avec la m�me instance de VC++. C'est pourquoi je pense qu'il faut autant de VC++ ouverts que d'exe � d�boguer.

[maphi]

Oui, m�me avec la fonction assert, il m'ouvre un nouveau visual pour le debug. Mais il s'ouvre tou seul :-)

Bref, c'est mal parti cette histoire...

Pour le fait qu'il m'ouvre pas les sources, est ce que ca peut etre du au fait que tous les exe (plus un paquet de dll) partagent le meme dossier de sortie ?

[farscape]

moi a part dire je debug sur l'appli principal ,
et j'ouvre une autre instance de visual dont j'attache le debugger au nouveau process lancer .
je vois pas comment tu peux faire autrement .

[Aurelien.Regat-Barrel]

Je sais pas si tu as compris ce que je voulais dire : le debugger il peut suivre que un seul process � la fois. Normal : les registres, le pas � pas, etc... tout �a est sp�cifique � 1 process. Il te faut ouvrir autant de VC++ que tu as d'exe � d�boguer.
Mais question b�te : si tu le lances depuis system(), il est tr�s facile de faire pareil depuis le debuger en donnant les arguments que tu veux en ligne de commande. Quelle diff�rence entre
- lancer depuis system dans une autre appli
- bricoler pour ouvrir VC++ et c�er une session de d�bogage
et
- lancer en debug directement depuis VC++
� part la simplicit� de la 2� ?

[maphi]

Je sais pas si tu as compris ce que je voulais dire : le debugger il peut suivre que un seul process � la fois. Normal : les registres, le pas � pas, etc... tout �a est sp�cifique � 1 process. Il te faut ouvrir autant de VC++ que tu as d'exe � d�boguer.
Mais question b�te : si tu le lances depuis system(), il est tr�s facile de faire pareil depuis le debuger en donnant les arguments que tu veux en ligne de commande. Quelle diff�rence entre
- lancer depuis system dans une autre appli
- bricoler pour ouvrir VC++ et c�er une session de d�bogage
et
- lancer en debug directement depuis VC++
� part la simplicit� de la 2� ?

Si, j'ai bien compris.

Par contre, je ne peux pas lancer directement la plupart des exe. L'architecture du soft est assez compliqu�e (je ne la ma�trise pas du tout pour l'instant).

Pour faire simple, c'est du client/serveur.
On a 1 exe principal qui va lire des variables d'environnement et analyser la structure des dossiers (entre autres choses) puis lancer en fonction de ca des exe serveur ou client.

Maintenant, du cot� client par ex., l'exe principal d�finit un contexte d'ex�cution sans lequel les exe clients ne peuvent pas se lancer.

Je peux pas en dire bcp plus vu la ma�trise que j'ai pour l'instant sur le code.

Sinon, y a t'il un inconv�nient � ce que tous mes projets aient le m�me dossier de sortie pour le debug (pareil, apparement visual stocke des infos dans un vc60.pdb, qui du coup est ecras� � chaque compil de projet) ?

[Aurelien.Regat-Barrel]

Mieux vaut avoir chacun son debug. Ca n'emp�che pas de cr�er l'exe ailleurs que dans le debug.