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.