Le titre du sujet veut tout et en même temps rien dire.
En faite j'ai un problème avec VS C++ ou alors avec Windows :
Je créer sous visual un projet vide. Le programme doit me créer un fichier résultat.
Donc je lui indique le chemin du fichier de sortie : "./fichierResultat.txt"
pour que le fichier soit créé au niveau de mon exécutable.
Et c'est là que ça se complique : le fichier créé en sortie, se postionne dans le dossier C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT
Bref, un dossier que je ne connaissais même pas avant de faire une recherche sur mon dossier résultat.
Donc j'aimerais savoir comment puis-je imposer à mon projet/compilateur (certainement via une option sous Visual), que le repertoire courant soit positionné au niveau de mon exécutable.
PS : Via un projet de type console je n'est pas ce problème mais de cette maniere, l'exécutable est dépendant de nombreuses bibliothèques que tous les windows ne possède pas.
Ben c'est que c'est le comportement par défaut ça. Enfin pas au niveau de l'exécutable, c'est à dire pas dans Debug ou Release.
Le répertoire de l'application par défaut est à la racine du projet, c'est à dire la valeur de la macro $(SolutionDir)
Justement je voulais apporter des précisions sur mon problème.
Déjà je vais préciser le comportement de mon programme :
- exe de type console.
- En entrée le programme reçoit en argument un nom de fichier à analyser. (FE)
- En sortie un fichier résultat (FS).
En fait, effectivement le répertoire par default est bien celui de l'exécutable mais mon programme peu se comporter de plusieurs manières :
Si je fais glisser un fichier (FE) sur mon exécutable, pour le faire passer comme argument à mon programme : j'ai le problème de répertoire.
Si j'exécute de maniere correcte c'est à dire via la console, en precisant les chemins d'exécution pas de problème.
Bref la cause du problème, comme toujours en programmation, vient de celui qui code, cad de moi moi ! :P :oops:
Mais si vous avez une méthode pour que le glisser/déposer fonctionne je suis preneur :D
Le moins que l'on puisse dire est que ceci n'a pas grand chose à voir avec la question de départ :D
Ma foi oui, j'en ai une: rien :D
Il n'y a rien à faire. Ton appli console étant
int main(int argc , char** argv)
{
// etc
}
En argv[0] tu as le nom de ton exe avec son chemin complet
en argv[1] tu as le nom du fichier glissé dessus, avec son chemin complet
Et si tu lances depuis Visual, ben... c'est pareil.
Oui mais....
Je m'explique mieu (ou je vai_s essayer) :
J'écris en premières lignes du main, le code (via C++ & Boost) permettant de récupérer le chemin d'origine de mon exe en dur !
Je compile!
Je lance mon application en cliquant sur l'exe il me retourne pour le répertoire de l'exe ceci : C:/MonAppli/
Si toujours avec le même exécutable, je l'exécute en lui passant un fichier (via glisser/déposer), là, il me retourne pour le répertoire de l'exécutable ceci :
C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT
Deux comportements différents si je fais ou non un glisser/déposer.
Effectivement ça diffère de ma question mais je ne le savais pas au départ :oops:
Ducoup je suis obligé de mettre en dur le chemin vers l'arborescence pour mon répertoire ou seront stockés mes fichiers résultats : cela impose à l'utilisateur de placer sur un endroit bien précis tout les fichiers (exe + repertoire de stockage des fichiers résultats)
Excellent. Que voilà un garçon qui a du goût :D
Jusque là, je suis...
Sûr ? Parce que ... ->
... -> Mon bon k-lo, je suis obligé de te contredire. Ca ne fait pas ce que tu dis que que ce soit un glisser-déposer ou non. J'affirme. Car hier soir, intrigé par ta question, j'ai fait l'essai moi même avec mes petits doigts potelés, et bien regardé le résultat avec mes petits yeux porcins :D
Bref ça fait pas ce que tu dis et j'ai un comportement à l'identique dans tous les cas.
Maintenant ça:
Encore ça ? Mais qu'est-ce que c'est que cette facétie :?: Pourquoi il apparaît ce répertoire. Déjà dans ta question d'hier on aurait pas du voir ça.
Alors que se passe-t-il ? Je ne sais pas. Mais je me demande si tu n'aurais pas une configuration de déboggage assez "spéciale", de derrière les fagôts, sur ton VS ou sur ton Windows. Est-ce que ça fait la même chose après compilation en mode Release ?
C'est à cause de Programmez enfin je devrais dire grâce à Programmez :P !
Malheureusement je suis certain de ce que j'avance. de m^me pour le répertoire
C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT
Je veux bien te croire pour le déboggage et j'ai le même problème pour le mode Release... mais je n'ai pas ce problème si j'utilise une application de type console (d'où le nom du sujet "projet vide") c'est pour ça que je fini par ne rien n'y comprendre.
Si je ne fais pas une application console s'est que ça rends le programme trop dépendant de la machine où ça été compilé.
Bon je verai ceci a tête reposer et depuis 0. peut être que j'ai fais une coquille et que je manque de recul pour la voir.
Merci fredericmazue!
Ceci est pour moi un mystère.
Comme quoi on ne connaît jamais vraiment Windows.... :evil:
Je vois pas en quoi une application console est dépendante de la machine de compilation. Je sais que tu as dit un mot là dessus dans ton premier message, mais je dois dire que je n'ai pas compris. Enfin tu dois avoir tes raisons.
Mais console ou pas, j'ai refait des essais. Je n'arrive pas à obtenir la même chose que toi.
La seule différence entre console et Win32 est que dans la ligne de commande, le nom de l'appli est présent en console et seulement le fichier glissé-déposé en Win32
Pas trace de "C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT"
J'ai relu ta question initiale.
Quoi qu'il en soit des facéties de Windows, il me semble qu'en écrivant 2 ou 3 lignes de code à base de GetModuleFileName et de SetCurrentDirectory tu dois pouvoir régler ton problème.
En fait j'ai recupéré l'arborescence exacte du répertoir pris pour "./" depuis mon exe :
C:/ProgrammesFiles/Fichiers Communs/System/MAPI/1036/NT
Effectivement : parce que sur une autre machine ça fonctionne pas :shock:
Soit il me dit qu'il me manque des bibnliothèques de microsoft pour l'exe soit il me dit que le programme à mal été installer (je ne fais pourtant pas d'installeur). Peut être a cause du stdafx.h et stdafx.cpp qu'il me rajoute par défaut.
D'où le fait qu'utiliser les fonctions GetModuleFileName et de SetCurrentDirectory me poserait le même problème ?
Je vais tester donc :D
Je suis tomber sur ce site http://torment.warparadise.com/index.php?page=download et 1 personne parle d'un Le convertisseur ACM-Wave qui aurait le même problème :?
Hum, la MAPI
Comme c'est étrange. Elle est censée faire quoi ton application ?
Qui "il" :?:
Quelles bibliothèques. :?:
Bon sang, tu peux pas être un peu plus précis ou mieux nous montrer un message d'erreur.
Qui "il" :?:
Bon ça, ça peut être un pb lié à MSI, mais faut voir. Pas vraiment assez de renseignement pour trancher pour l'instant.
Rien à voir
Mais non, bien sûr que non
Pardonne moi (je ne le dit pas pour te peiner) mais ce que tu racontes n'a aucun sens.
Il n'y aucune raison qu'une application console ne trouve pas des bibliothèques pour la bonne et simple raison qu'une application console utilise les mêmes bibli qu'une application à fenêtre.
Idem pour GetModuleFileName et SetCurrentDirectory qui sont des APIs présentes dans tous les Windows de l'univers.
Par contre quand je prends ton affaire globalement, avec l'histoire du "mal installé", on dirait que tu as un conflit de nom quelque part et que tu écrases avec ton exécutable un exécutable préablement installé avec MSI et appartenant à une autre application. Ca pourrait tout expliquer, y compris ce répertoire MAPI qui serait utilisé par l'autre application en temps normal. Et y compris ces histoires Console/Win32 selon ce qu'est l'application écrasée
Moi je chercherais dans cette direction avant de continuer à coder quoi que ce soit.
Il s'appelle comment l'exe que tu codes ?
Analyser un fichier n'ayant pas un formatage particulier (txt par exemple)!
Windows avec un jolie warning. Soyons précis effectivement ça serait mieu - voici le message lorsque je fais tourner mon fichier sous
Windows 2000 :
Le même exécutable sous XP :
Oula c'est moi qui vient avec mon problème alors n'utilise pas de pincettes pour me répondre :wink:
Et en plus ce que tu me dis me rassure...
Alors mon application s'appele : AnalyseKlo.exe et comme toujours il a le même non que mon projet VS et ça me le fait pour tout ce qui n'est pas projet vide !
J'ai du louper un gros truc moi avec Windows ou/et Visual :(
PS : je n'est pas encore fini mon message ...
[edit]car je crois que ça vient de ma compilation avec Visual : mettre en /MD
Bon ça c'est très facile.
C'est une bibliothèque de débogage de Visual 2005.
A prioiri quand tu déploies sur une machine, c'est qu'avant tu as compilé en Release. Et le problème s'élimine. :)
Bon ça c'est le même que celui d'avant. Windows se comprend, à défaut d'être compréhensible :)
Dis, regarde ta base de registre et dis moi ce que tu as comme valeur pour cette cle
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\AeDebug\Debugger
Et va voir un peu dans ton Visual à Options|Debugging, s'il n'y aurait pas une case à décocher. (Pour l'instant je ne sais pas laquelle)
En mode release ou en debug (/mD ou /MDd), j'ai la même erreur :(
ça me retourne C:\WINDOWS\System32\vsjitdebugger.exe" =p %ld -e %ld
Ca me parait correct.
Pour tout le reste, je ne comprends rien, je dois avouer.
Ton histoire de répertoire NT/MAPI et compagnie est un mystère pour moi.
Je commence à me poser la question qui tue....
Qui dit MAPI qui messagerie électronique. Et comme ton appli n'est pas du tout une appli de messagerie si je comprends bien, alors je commence à me demander si tu n'aurais pas un virus sur ta bécane ?
Qu'un exécutable aille se placer tout seul dans C:/ProgrammesFiles/Fichiers Communs/System/MAPI/1036/NT après compilation sous Visual, je ne l'ai jamais vu, et franchement ça me dépasse....
Là on s'est pas compris (dsl je m'exprime pas toujours correctement :oops: ).
En fait l'exécutable ne se place pas du tout dans ce dossier MAPI/NT (Non aucun rapport avec une messagerie)
mon code (de mémoire) :
path p = complete (path("./", native)); cout << p.leaf();Je compile le projet!
2 cas :
1) je clique sur mon exe (console) qui se trouve bien dans c:/monprojet/ (par exemple)
sortie : C:/monprojet/
2) Je fais un glisser déposer d'un fichier .txt (qui me sert pour la suite du programme) sur ce MEME exe et qui se trouve au même niveau que mon exe.
sortie : C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT
Bref deux comportements différents en fonction si mon programme reçoit ou non un argument ! En fait il perderait le chemin :?
Et j'ai remarqué ce comportement que sur des projets vides (va&riable d'environnement perdue ??)
Tu t'es bien exprimé, c'est moi qui a tout mélangé pour le coup :oops:
MAIS...
... C'est bien ce que tu as toujours dis, mais ce n'est pas normal. Je n'ai jamais vu ça en tous cas.
Très intrigué, j'ai même essayé de le reproduire sur une de mes bécanes et je n'y suis pas arrivé...
Rien à voir, à mon avis du moins.