[Visual Studio C++] Projet vide et Répertoire courant

K-lo
[Visual Studio C++] Projet vide et Répertoire courant

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.

fredericmazue

Quote:
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.

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)
K-lo

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

fredericmazue

Quote:
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.

Le moins que l'on puisse dire est que ceci n'a pas grand chose à voir avec la question de départ :D
Quote:

si vous avez une méthode pour que le glisser/déposer fonctionne je suis preneur

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.

K-lo

fredericmazue wrote:
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)

fredericmazue

Quote:
via C++ & Boost

Excellent. Que voilà un garçon qui a du goût :D
Quote:
Je lance mon application en cliquant sur l'exe il me retourne pour le répertoire de l'exe ceci : C:/MonApp

Jusque là, je suis...
Quote:
Si toujours avec le même exécutable,

Sûr ? Parce que ... ->
Quote:
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.

... -> 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:

Quote:
C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT

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 ?
K-lo

fredericmazue wrote:
Quote:
via C++ & Boost

Excellent. Que voilà un garçon qui a du goût :D

C'est à cause de Programmez enfin je devrais dire grâce à Programmez :P !

fredericmazue wrote:
Sûr ? Parce que ... ->

Malheureusement je suis certain de ce que j'avance. de m^me pour le répertoire
C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT

fredericmazue wrote:
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 ?

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!

fredericmazue

Quote:
C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT

Ceci est pour moi un mystère.
Comme quoi on ne connaît jamais vraiment Windows.... :evil:

Quote:
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é.

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.

K-lo

fredericmazue wrote:
Quote:
C:/ProgrammesFiles/Fichiers Communs/System/(...)/NT

Ceci est pour moi un mystère.

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

fredericmazue wrote:
Quote:
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é.

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.

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
K-lo

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 :?

fredericmazue

Quote:
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

Hum, la MAPI
Comme c'est étrange. Elle est censée faire quoi ton application ?

Quote:
Soit il me dit qu'il me manque des bibnliothèques de microsoft pour l'exe

Qui "il" :?:
Quelles bibliothèques. :?:
Bon sang, tu peux pas être un peu plus précis ou mieux nous montrer un message d'erreur.

Quote:
soit il me dit que le programme à mal été installer

Qui "il" :?:
Bon ça, ça peut être un pb lié à MSI, mais faut voir. Pas vraiment assez de renseignement pour trancher pour l'instant.

Quote:
Peut être a cause du stdafx.h et stdafx.cpp qu'il me rajoute par défaut.

Rien à voir

Quote:
D'où le fait qu'utiliser les fonctions GetModuleFileName et de SetCurrentDirectory me poserait le même problème

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 ?

K-lo

fredericmazue wrote:

Hum, la MAPI
Comme c'est étrange. Elle est censée faire quoi ton application ?

Analyser un fichier n'ayant pas un formatage particulier (txt par exemple)!

fredericmazue wrote:

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" :?:

Windows avec un jolie warning. Soyons précis effectivement ça serait mieu - voici le message lorsque je fais tourner mon fichier sous
Windows 2000 :

Quote:
La bibliothèque de liaison dynamique MSVCP80D.dll est introuvable sur le chemin spécifier C:\test (la ou se trouve mon exe) C:\WINNIT\System32; C:\WINNIT\System;C:\WINNIT\;C:\Program Files\Adobe\AGL;C:\Program Files\QuickTime\QTSystem

Le même exécutable sous XP :

Quote:
Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. Réinstaller cette application pourrait résoudre se problème.

fredericmazue wrote:
Pardonne moi (je ne le dit pas pour te peiner) mais ce que tu racontes n'a aucun sens.

Oula c'est moi qui vient avec mon problème alors n'utilise pas de pincettes pour me répondre :wink:

fredericmazue wrote:
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.

Et en plus ce que tu me dis me rassure...

fredericmazue wrote:

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 ?

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

fredericmazue

Quote:
La bibliothèque de liaison dynamique MSVCP80D.dll est introuvable sur le chemin spécifier

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. :)

Quote:
Cette application n'a pas pu démarrer car la configuration de l'application est incorrecte. Réinstaller cette application pourrait résoudre se problème.

Bon ça c'est le même que celui d'avant. Windows se comprend, à défaut d'être compréhensible :)

Quote:
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
Ce n'est pas normal.

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)

K-lo

fredericmazue wrote:
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.

En mode release ou en debug (/mD ou /MDd), j'ai la même erreur :(

fredericmazue wrote:
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


ça me retourne C:\WINDOWS\System32\vsjitdebugger.exe" =p %ld -e %ld
fredericmazue

Quote:
ç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....
K-lo

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 ??)

fredericmazue

Quote:
Là on s'est pas compris (dsl je m'exprime pas toujours correctement Embarassed ).
En fait l'exécutable ne se place pas du tout dans ce dossier MAPI/NT (Non aucun rapport avec une messagerie)

Tu t'es bien exprimé, c'est moi qui a tout mélangé pour le coup :oops:

MAIS...

Quote:
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


... 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é...
Quote:
(va&riable d'environnement perdue ??)

Rien à voir, à mon avis du moins.