Nach einem Aufruf von GetOpenFileName() kann ich keine Dateien mehr erstellen! Zumindest nicht im Verzeichnis, wo auch die .exe liegt. Auf C:\\ zB. geht es...

Woran liegt das? Ich kann es mir einfach nicht erklären!
Es ist absolut komisch!

Die .exe liegt in "C:\\DATA\\C++\\Projects\\Log\\Debug".
Nach einem Aufruf von GetOpenFileName():

logFile.open("C:\\bla.txt", ios::out); // Funktioniert
logFile.open("bla.txt", ios::out); // Funktioniert NICHT, KEINE Fehlerflags!
logFile.open("folder\\bla.file", ios::out); // Funktioniert NICHT, "fail" Fehlerflag...

Und das ganze passiert nur, wenn ich auch eine Datei im Open File Dialog auswähle. Wenn ich gleich wieder auf Cancel klicke, tritt das Problem nicht auf. Es ist aber egal welche Datei ich anwähle, außerdem mache ich ja nix mit ihr...

char filePathName[MAX_PATH];
OPENFILENAME openFileName = { };
openFileName.lStructSize = sizeof(OPENFILENAME);
openFileName.hwndOwner = windowHandle;
openFileName.lpstrFile = filePathName;
openFileName.lpstrFile[0] = '\0';
openFileName.nMaxFile = MAX_PATH;
openFileName.lpstrFilter = "All\0*.*\0";
openFileName.nFilterIndex = 1;
openFileName.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST;
GetOpenFileName(&openFileName);

Was pfuscht Windows da?

Und ja, das war unter Windows schon immer so, "pfuschen" würd' ich das nicht nennen. Ich find's auch doof - aber es heißt ja schließlich "aktuelles" verzeichnis, nicht "Verzeichnis, das mal aktuell war, als das Programm gestartet wurde".

Also: aktuelles Verzeichnis (oder gleich EXE-Verzeichnis? kommt drauf an...) beim Programmstart merken, und immer absolute Pfade basteln.

char currentDirectory[MAX_PATH];
GetCurrentDirectory(MAX_PATH, currentDirectory); 
GetOpenFileName(&openFileName);
SetCurrentDirectory(currentDirectory);

Davon mal abgesehen, ist es eine ganz schlechte Idee im Programmverzeichnis Dateien schreiben zu wollen, da dort nur der Adminsitrator Schreibrechte hat und unter Vista auch nur dann wenn er explizit Administratorenrechte anfordert.

Programmeinstellungen werden entweder in der Registry gespeichert oder im Profilverzeichnis des Benutzers unter AppData\<Programmname>.

Da wird nichts gefuscht. Der Fehler liegt beim Programmierer. GetCurrentDirectory gibt das aktuelle Verzeichnis aus und dieses wird nun mal geändert wenn man mit dem Datei-Öffnen-Dialog eine Datei auswählt und das Verzeichnis wechselt. Mit GetModuleFilen(Ex) bekommst du den Pfad und den Dateinamen deiner Exe-Datei.

Wenn's dokumentiert wäre (Zumindest auf der ersten Seite steht nix davon, sollte es aber...)

Luckie schrieb:

Davon mal abgesehen, ist es eine ganz schlechte Idde im Programmverzeichnis Dateien schreiben zu wollen, da dort nur der Adminsitartor Schreibrechte hat und unter Vista auch nur dann wenn er explizit Administratorenrechte anfordert.

Egal, das Programm ist nur für mich.

Luckie schrieb:

Progarmmeinstellungen werden entweder in der Regsitry gespeichert oder im ProfilVerzeichnis des Benutzers unter AppData\<Programmname>.

Schon klar.

MfG

Retrieves the current directory for the current process.

openFileName.Flags = OFN_PATHMUSTEXIST | OFN_FILEMUSTEXIST | OFN_NOCHANGEDIR;

@Meister Propper
"Windows NT 4.0/2000/XP: This flag is ineffective for GetOpenFileName"
War mir da unsicher...

MfG

Das Verzeichnis kann in einem Shortcut separat angegeben werden, beim Start von der Konsole wird das aktuelle Verzeichnis vom rufenden Prozeß geerbt.

Dein Programm kann also unter c:\nurfuermich\ liegen, das aktuelle Verzeichnis liegt aber auf einem CD-ROM - Laufwerk - viel Spaß beim Schreiben!

"Lokaler" Dateizugriff sind trotzdem manchmal sinnvoll - z.B. für Kommandozeilen-Tools.

@Meister Propper
"Windows NT 4.0/2000/XP: This flag is ineffective for GetOpenFileName"
War mir da unsicher...

Oh. In meiner Hilfe taucht dieser Hinweis noch gar nicht auf (Oktober 2001).