Discussion :

[MiniGeek]

Bonjour,

Je rencontre un problème qui me laisse perplexe...
je souhaite récupérer le chemin de l'exécutable pour pouvoir en extraire le chemin du dossier "précédent".
Je rencontre un problème en utilisant GetModuleFileName. En effet, j'ai plusieurs variables globales qui sont initialisée au début:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
CString m_strExportDir;
	CString m_strJournalDir;
	CString m_strArchiveDir;
	CString m_strServeur;
	CString m_strBase;
	CString m_strLastUser;
	CString m_strCheminRacine;

Quand j'appelle dans le cpp:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

GetModuleFileName(NULL,(char*)(LPCTSTR(m_strCheminRacine)),512);

toutes les variables globales prennent le chemin de l'exe (qui est soit dit en passant le chemin attendu mais ce chemin ne devrait normalement être stocké que dans m_strCheminRacine).
C'est mon premier problème.

Ensuite quand je tente un

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
CString chemin2=m_strCheminRacine;
	m_strCheminRacine=chemin2.Left(11);

rien ne se passe je ne parviens pas à extraire la partie gauche de mon chemin...

je ne comprends pas pourquoi ça ne marche pas d'autant plus que le même code marchait parfaitement bien sous VC6.0 avant que je ne le transfère sous VS2008...

(je donne en passant une précision qui ne sert peut-être à rien: j'utilise pour compiler les MFC en DLL partagée et je n'utilise pas ATL. Quand j'utilise ATL en DLL partagée, cela ne change rien à mon problème...)

Quelqu'un aurait-il la moindre idée d'où pourrait provenir cette erreur?

Merci beaucoup par avance!

[bacelar]

Il y a plusieurs classes CString, en fonction des options de compilation.

Quelle est celle utilisée ?

Pouvez-vous poster une solution VS2008 minimaliste, reproduisant le problème ?

[farscape]

salut,
ça ne fonctionne pas et ce n'est pas étonnant ^^,
la définition de la fonction:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
 
DWORD WINAPI GetModuleFileName(
  __in_opt  HMODULE hModule,
  __out     LPTSTR lpFilename,
  __in      DWORD nSize
);

lpFilename est la chaine de sortie , donc mettre une CString avec un horrible cast à la C
ne peut que provoquer des problèmes.
il faut que tu déclares une chaine:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
 
TCHAR szRacine[MAX_PATH];
GetModuleFileName(NULL,szRacine,MAX_PATH);
m_strCheminRacine=szRacine;

[MiniGeek]

Bonjour,

Merci beaucoup de la réponse, effectivement maintenant ça marche.

enfin ce bout de code là marche du moins...
je me permet de demander une petite précision: le code qui pose problème proviens de la migration d'un projet VC6.0 vers VS2008. Lors de l'exécution, pleins d'erreurs apparaissent (liées à des char non identifiés par exemple...) (en fait je me demande si la moindre fonction marche correctement). Toutes ces erreurs sont-elles plutôt dues au fait que le compilateur de vs2008 est nettement moins permissif que celui de vc6.0 ou à un problème autre (genre un problème qui serait apparu lors de la migration, dll corrompue???)?
je penche plutôt pour la première solution, ce qui a tendance à me désespérer... enfin bref.

en attendant merci pour votre aide!!!

[farscape]

salut,
en principe tu ne devrais pas avoir trop de problèmes de migration de vc6 a vs2008.
il faudrait que tu sois plus précis quand à la nature des erreurs, néanmoins vérifie le paramétrage du jeux de caractères dans le projet (onglet général)
sous VS2008 le réglage par défaut est l'unicode.

[bacelar]

La classe CString de VC++6 et de VS2008 n'ont plus grand chose de commun.

Il y a peut-être des options, comme ASCII à la place d'UNICODE, qui permettront d'utiliser une classe CString aussi misérable que celle de VC++6.
Mais je profiterais de l'occasion pour utiliser correctement la classe CString de VS2008 et enlever tout le code qui utilise de travers les CStrings, comme le code que vous avez fournit.

Utilisation calamiteuse d'une string comme char* sans passer par un getBuffer, non allocation préalable des 512 octets spécifiés dans l'appel, si le programme est tombé en fonctionnement, c'est par hasard.