Pfad einlesen

JochenSt

hab jetzt komplett auf die windows.h verzichtet und mein problem wie folgt gelöst. falls jemand mal ähnliche probleme hat poste ich hier mal noch meine lösung hinzu.
die direct.h hat sich für mich einfach als unproblematischer bezüglich funktionsüberschreibungen entpuppt und sie liefert mir das ergebnis auch gleich im richtigen format.

#include <direct.h>
.
.
.
char buffer[256];
_getcwd( buffer, 256);

Jochen Kalmbach

_getcwd liefert das *aktuelle* Verzeichnis! Das muss nicht unbedingt mit dem Verzeichnis der EXE übereinstimmen (vor allem, wenn die EXE über COM oder Links gestartet wird!)

sri

_targv[0] sollte eigentlich auch auf den Namen der auszuführenden Datei zeigen.

peterchen

getcwd ist wirklich eine ganz schlechte Idee.
Das aktuelle Verzeichnis ändert sich schnell mal - z.B. beim Aufruf des File-Dialogs.

_targv[0] kann glaub' ich vom Aufrufer manipuliert (bzw. muß richtig gesetzt) werden.

insofern würde ich auch zu GetModuleFileName raten.

Wir haben da mal was vorbereitet...
http://www.codeproject.com/KB/files/phShellPath.aspx

Leider fehlen in dem Code noch ein paar Anpassungen auf Unicode

Jochen Kalmbach

sri schrieb:

_targv[0] sollte eigentlich auch auf den Namen der auszuführenden Datei zeigen.

Sollte... muss es aber nicht... starte mal ein Programm mit "CreateProcess("NameDerExe.exe Param1", NULL, ..."); dann siehst Du dass die meisten Programme hier Fehler machen

sri

Jochen Kalmbach schrieb:

sri schrieb:

_targv[0] sollte eigentlich auch auf den Namen der auszuführenden Datei zeigen.

Sollte... muss es aber nicht... starte mal ein Programm mit "CreateProcess("NameDerExe.exe Param1", NULL, ..."); dann siehst Du dass die meisten Programme hier Fehler machen

Gut zu wissen.

JochenSt

das mit dem verlinken bzw. über com öffnen könnte dann natürlich ein problem werden.
das problem was ich mit GetModuleFileName(...) habe ist das ich die windows.h einbinden muss und das führt zu funktionsüberlagerungen. wie ich in folgendem thread beschrieben habe.

http://www.c-plusplus.net/forum/viewtopic-var-t-is-220396.html

die funktionen umzubennen bzw. einen namespace zu geben ist nicht so ganz einfach weil das projekt zu groß ist und ich nur in einem kleinen bereich herumprogrammieren kann.
#define NOWINSOCK klappt auch nicht weil diese flag nicht in der windows.h aufgeführt ist.

jetzt muss ich mir wohl doch noch was neues einfallen lassen, weil irgendwie muss ich den pfad einlesen und arg[0] liefert lediglich den namen der exe nicht pfad.
Und ich dachte ich habe so eine gute lösung gefunden

Hallo,

wenn du es dir leisten kannst, gäbe es noch die Makros VC_EXTRALEAN und WIN32_LEAN_AND_MEAN, die, wenn definiert, u.a. winsock2.h ausschliessen würden.

MfG,

Probe-Nutzer

Jochen Kalmbach

Dann schreib Dir halt *eine* ganze kleine CPP:

gmfn.cpp

#include <windows.h>
extern "C" void GetEXEDir(LPTSTR szDirName, SIZE:T nBuffSize)
{
  // GetModuleFileName....
}

Und diese Funktion verwendest Du dann in Deinem "großen" Projekt... damit musst Du windows.h nicht in Dein "großes" Projekt einbinden...

JochenSt

ihr habt mir echt sehr viel geholfen, sowohl die variante von probe-nutzer als auch jochen kalmbach funktionieren super und ich hab noch ne menge dabei gelernt.

danke tolles forum

hier mal noch jetzt meine lösung, ich hoffe sie wird nicht so auseinander genommen wie die letzte

#define WIN32_LEAN_AND_MEAN

#include <windows.h>

void GetEXEDir(char *DirName,int MaxCharSize){
TCHAR szFileName[256];
char help[256];
GetModuleFileName(NULL, szFileName, sizeof(szFileName) / sizeof(TCHAR));
wcstombs( help, szFileName,MaxCharSize );
while(help[MaxCharSize] != '\'){
MaxCharSize--;
}
strncpy(DirName, help, MaxCharSize);
}