Répertoire courant lors d'une association de fichiers
11 réponses
Stan
Bonjour,
je développe une appli en visual C++ ( visual studio .net ) qui exploite des
fichiers en .jpg.
J'ai fait une association de fichiers pour ouvrir cette appli
automatiquement lorsque je double-clique un fichier jpg.
Mon problème est que pour fonctionner, mon appli fait appel à d'autres
fichiers qui se trouvent sur le meme répertoire que l'appli. Lorsque je
double clique un jpg, l'appli ne trouve pas les autres fichiers nécessaires
à son fonctionnement puisque le répertoire courant est celui du jpg. Comment
retrouver en C++ le répertoire sur lequel est stocké mon appli ? Merci pour
votre aide.
Bertrand Lenoir-Welter a écrit : > Là, vous m'étonnez. A mon sens, au point d'entrée d'un programme EXE,
l'argument 0 est toujours le nom de l'exécutable avec son chemin d'accès complet, quel que soit le processus lanceur. En tout cas, c'est comme ça que j'ai toujours fait et j'ai jamais eu un problème signalé.
#include <dir.h>
int main(int ArgNb, char *ArgStr[]) { fnsplit(ArgStr[0],DriveStr,DirStr,NameStr,ExtStr); // fait le reste }
Bon, je ne sors jamais de Windows, désolé. Mais il me semble que le post original parlait de Visual C++, ce qui laisse présumer que c'est aussi le cas.
Sauf qu'il utilise probablement :
#include <windows.h>
int WINAPI WinMain(HINSTANCE hMainInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) { [...] }
ici lpCmdLine ne contient pas le nom du programme, et GetCommandLine() ne renvoie qu'un chemin relatif, donc le mieux est toujours GetModuleFileName().
-- Patrick
Bertrand Lenoir-Welter a écrit :
> Là, vous m'étonnez. A mon sens, au point d'entrée d'un programme EXE,
l'argument 0 est toujours le nom de l'exécutable avec son chemin d'accès
complet, quel que soit le processus lanceur. En tout cas, c'est comme ça
que j'ai toujours fait et j'ai jamais eu un problème signalé.
#include <dir.h>
int main(int ArgNb, char *ArgStr[]) {
fnsplit(ArgStr[0],DriveStr,DirStr,NameStr,ExtStr); // fait le reste
}
Bon, je ne sors jamais de Windows, désolé. Mais il me semble que le post
original parlait de Visual C++, ce qui laisse présumer que c'est aussi
le cas.
Sauf qu'il utilise probablement :
#include <windows.h>
int WINAPI WinMain(HINSTANCE hMainInstance, HINSTANCE hPrevInstance,
LPSTR lpCmdLine, int nShowCmd)
{
[...]
}
ici lpCmdLine ne contient pas le nom du programme, et GetCommandLine()
ne renvoie qu'un chemin relatif, donc le mieux est toujours
GetModuleFileName().
Bertrand Lenoir-Welter a écrit : > Là, vous m'étonnez. A mon sens, au point d'entrée d'un programme EXE,
l'argument 0 est toujours le nom de l'exécutable avec son chemin d'accès complet, quel que soit le processus lanceur. En tout cas, c'est comme ça que j'ai toujours fait et j'ai jamais eu un problème signalé.
#include <dir.h>
int main(int ArgNb, char *ArgStr[]) { fnsplit(ArgStr[0],DriveStr,DirStr,NameStr,ExtStr); // fait le reste }
Bon, je ne sors jamais de Windows, désolé. Mais il me semble que le post original parlait de Visual C++, ce qui laisse présumer que c'est aussi le cas.
Sauf qu'il utilise probablement :
#include <windows.h>
int WINAPI WinMain(HINSTANCE hMainInstance, HINSTANCE hPrevInstance, LPSTR lpCmdLine, int nShowCmd) { [...] }
ici lpCmdLine ne contient pas le nom du programme, et GetCommandLine() ne renvoie qu'un chemin relatif, donc le mieux est toujours GetModuleFileName().
