Konfigurationsdateien in C++

[Junta]

Mal sehen, ob ich das so umgeschrieben bekomme (sollte das kleinere Übel sein).
Nun ist mir leider was Anderes aufgefallen. Bekommt eine Variable einen Pfad per Öffnen-Dialog (ich weiß nicht, ob Borland da über die WinAPI geht) kann ich die zumindest mit

Code:

fprintf(cfg, "path = %s\n", varValue)

nicht schreiben. Trag' ich den Pfad von Hand ein geht's. Jedoch nach dem Versuch den per Öffnen-Dialog übergebenen Pfad zu speichern, schlägt auch die Handeingabe fehl (sprich er erstellt keine Datei bzw. überschreibt die Alte nicht). Irgendwas muss da ja (aufgrund eines unsichtbaren (halt ungültigen) Zeichens, was weiß ich) blockieren.
Hatte mich zunächst geärgert und gewundert, da es im Testprogramm 1A funktionierte. Da hatte ich den Pfad auch nur per Hand übergeben, was wohl mein Fehler war...
Irgendwelche Ideen?

[Rolus]

(ich weiß nicht, ob Borland da über die WinAPI geht)

...

Letztendlich sicher, eine andere Möglichkeit hat Borland ja gar nicht.

Jedoch nach dem Versuch den per Öffnen-Dialog übergebenen Pfad zu speichern, schlägt auch die Handeingabe fehl (sprich er erstellt keine Datei bzw. überschreibt die Alte nicht). Irgendwas muss da ja (aufgrund eines unsichtbaren (halt ungültigen) Zeichens, was weiß ich) blockieren.
Hatte mich zunächst geärgert und gewundert, da es im Testprogramm 1A funktionierte. Da hatte ich den Pfad auch nur per Hand übergeben, was wohl mein Fehler war...
Irgendwelche Ideen?

...

Ja, sieht ganz so aus, als ob bei dem Dialog das Problem liegen würde. Also würde ich mir mal die Dokumentation zu der entsprechenden Funktion anschauen, damit du siehst, ob du den Dateinamen richtig abfragst. Ansonsten poste mal den entsprechenden Code.

freundliche Grüße, Rolus

[Ineluki]

Die WinAPI stellt zum oeffnen, lesen, schreiben und bearbeiten von Dateien saemtlich eigene Funktionen zur Verfuefung. Wenn du also Dateinamen jenseits von 8.3 Zeichen verwenden willst, solltest du nicht die standard C-Funktionen unter Windows nutzen, sondern die Dateifunktionen und -handler der WindowsAPI, vor allem, wenn du ohnehin schon sowas wie den Oeffnen-Dialog von Windows verwendest. Als alte Faustregel gilt, mische so wenig wie moeglich Code von verschiedenen Quellen, d.h. fprintf/<< fuer die Console und CreateFile/OpenFile/ReadFile/WriteFile fuer WindowsAPI GUIs.

Ich bin damit auch mal auf die Nase geflogen ...

[Junta]

Also, fang' ich mal von Vorne an.
Den Dialog hatte ich ja auch schon als "Fehlerquelle" ausgemacht. Die CBuilder Doku sagt dazu ja Folgendes:

Header

vcl/dialogs.hpp
TOpenDialog erzeugt ein Dialogfeld, in dem der Benutzer eine Datei auswählen kann.

Beschreibung

TOpenDialog erzeugt ein Windows-Dialogfeld, in dem der Benutzer eine Datei auswählen und öffnen kann. Das Dialogfeld wird zur Laufzeit erst angezeigt, wenn es mit der Methode Execute aktiviert wird. Wenn der Benutzer auf öffnen klickt, wird das Dialogfeld geschlossen, und die ausgewählten Dateien werden in der Eigenschaft File gespeichert.

...

Wobei die Eigenschaft 'File' nicht existiert sondern nur 'FileName'.
Geöffnet und abgefragt wird der Öffnen-Dialog bei mir folgendermaßen:

Code:

void __fastcall TMainForm::ChangePathBtnClick(TObject *Sender)
{
	OpenDlg->Filter = "Ausführbare Dateien | *.exe";
	if(OpenDlg->Execute());
	{
		PathEdt->Text = OpenDlg->FileName;
		playerPath = PathEdt->Text;
	}
}

Stand, glaube ich, sogar so in der beiliegenden Hilfe.

@ine
Eigentlich hatte ich vor, so weit weg von der WinAPI zu arbeiten wie möglich. Was mir schon mit der verwendung von 'ShellExecute()' leider nicht geglückt ist (gibts einen anderen Weg ausser über 'system()'?). Ich möchte das Programm später eventuell mal auf Linux testen(weiß nich nicht mal, wie ich mir da die Oberfläche zusammenschnibbeln muss).

Ich hatte ja ausserdem selbst nicht vor verschiedenen Code zu mischen und fragte daher auch schon dach einer vergleichbaren Funktion von 'fprintf()' und 'fscanf()' in C++.

Zudem wollte ich eigentlich nur zur Übung abseits der Ausbildung ein Programm schreiben, da ich mich mit Programmieren ansonsten wohl nie beschäftigen würde (leider bin ich irgendwie noch nicht so weit, dass ich mich einfach vor ein gutes, das Thema betreffende, Buch setze anstatt drauf los zu Programmieren).

[Ineluki]

Wenn du portabel arbeiten willst, dann ist der Borland CBuilder eine gaaaaanz schlechte Wahl. Borland CBuilder ist zu C(++) das selbe, was Delphi zu ObjectPascal ist.

Fuer Portabilitaet empfehle ich einzig und allein die GCC und ein unabhaengiges GUI Toolkit. Borland CBuilder und Windows ist praktisch untrennbar.

[Junta]

Ich weiß, das habe ich schon zu Ausbildungsbeginn von meinem Lehrer erfahren. Deswegen schrieb ich ja auch, dass ich noch nicht weiß, wie ich mir da die Oberfläche zusammenbauen soll. Auf'm Amiga haben die das mit einem extra Editor gelöst. Die damit erstellte Datei ließ sich einfach in's Projekt einbinden.
(Memo an mich: am Programm weiterarbeiten.)

Das problem mit dem Öffnen-Dialog besteht übrigens auch bei Verwendung von 'ofstream'. Oder ich mach' einfach irgendwas falsch.

[Mog]

Schau dir doch einfach einmal GTK an. Das ist eine wunderschoene objektorientierte API in C geschrieben, die ziemlich plattformunabhaengig ist. Die Lizens ist auch ziemlich entwicklerfreundlich.


btw ist der ifstream und der ofstream in fstream zusammengefasst.

[Lysandros]

Wenn du lieber auf C++ stehst, kannst du dir auch Qt anschauen, was ich übrigens gerade mache.^^ Neben Tutorials auf der Homepage von Trolltech, habe ich auch noch ein eBook dazu gefunden und es gibt auch ein deutsches Forum.

[Junta]

Hmmm... ich häng' immernoch bei dem Problem mit dem Öffnen-Dialog... keiner mehr ne Idee? Um die Portierung (oder eher um das Umschreiben um das zu ermöglichen) wollte ich mich eigentlich erst kümmern, wenn die WinVersion läuft... möglich muss es ja sein, da genügend Leute ihre Pfade in irgendwelche Configs schreiben lassen.

[Mog]

Hmmm... ich häng' immernoch bei dem Problem mit dem Öffnen-Dialog... keiner mehr ne Idee? Um die Portierung (oder eher um das Umschreiben um das zu ermöglichen) wollte ich mich eigentlich erst kümmern, wenn die WinVersion läuft... möglich muss es ja sein, da genügend Leute ihre Pfade in irgendwelche Configs schreiben lassen.

...

Pruef einmal den Typ; vll ist das irgend ein dynamischer String.

[Junta]

Ne, ich bin so dumm... ich bin sowas von dumm. Der Öffnen-Dialog ändert leider auch den aktuell benutzten Pfad. Sprich, er schreibt schon in die Konfigurationsdatei. Er legt sie nur im Pfad der zuletzt ausgewählten Datei an... hmmm es müsste doch ne Möglichkeit geben (wird es wahrscheinlich auch) den aktuellen Anwendungspfad beim Starten des Programms abzufragen, oder?

Irgendwann hatte ich das mit dem Öffnen-Dialog schon gelesen... allein, dass ich das total verpennt hab ist schon schlimm *ärger*...

[Mog]

GetModuleFileName() sollte es tun. Das ist aber Windows-only. Das ganze gibt den Pfad+Programmname zurueck. Mit etwas RegExp sollte das aber np sein.