✔ Exception bei File-Auswahl

[langer1801]

Hallo,
ich habe ein Problem beim Nutzen eines CFileDialogs.

CMyFileDialog m_File (FALSE,"",buffer,OFN_HIDEREADONLY|OFN_OVERWRITEPROMPT,"Patientendateien  (*.pat)|*.pat| Alle Dateien|*.*||");
   if(m_File.DoModal()==IDOK)
   {
      pDoc->m_strDateiname = m_File.GetFileName();
   }

Die Klasse ist von CFileDialog abgeleitet, um die Beschriftungen ändern zu können. Ansonsten keine weiteren Änderungen.
Mein Problem: Immer wenn ich den File-Namen holen will in der hervorgehobenen Zeile, stürzt das Programm ab. Das Problem tritt auch auf, wenn ich den Standard-FileDialog benutze. In der MSDN ist der Aufruf aber auch so dokumentiert.
Letzte aufgerufene Funktion ist CStringData::IsLocked. Wo liegt das Problem?

Mfg

langer

 

[Endurion]

Ist pDoc an der Stelle auf einem gültigen Wert?

Wenn die Exception durch ein ASSERT im MFC-Code aufgerufen wird, dann spring mal zu dem Code da hin. Meistens steht dort eine Beschreibung des Fehlers.

 

[langer1801]

Hi,
pDoc ist schon richtig initialisiert. Und im Code der aufgerufenen Funktion steht als Rückgabewert

return nRef<0;

bedeutet gelockt.
Was mir jetzt aufgefallen ist, daß im Debug-Fenster für den Dialog

CMyDialog hwnd = 0x00000000

steht. Scheint kein gültiges Handle zu sein, obwohl der Dialog ordentlich angezeigt wird. Das Ganze geschieht übrigens in MainFrm.cpp.

Mfg

langer

 

[Endurion]

Jetzt fällts mir wieder ein: GetFileName war dafür gedacht, wenn man mit den Hooks rumspielt und INNERHALB des laufenden Dialogs den Text aus dem Edit holen will.

Nach DoModal ist der Dialog wieder weg, deshalb das HWND auf NULL. Versuch mal GetPathName stattdessen.

An der Stelle ist die MSDN ein bisschen unklar (keine Anmerkung dass das nur innerhalb von Hooks geht)

 

[langer1801]

Mit "GetPathName" erfolgt genau derselbe Absturz. Das Beispiel in der MSDN greift aber genauso nach DoModal auf die Funktion zu, also sollte die Implementierung eigentlich richtig sein. Warum es bei mir nicht klappt? Null Ahnung.

langer

 

[langer1801]

Hab nochmal experimentiert. Wenn ich schreibe

CString m_strDateiname=GetPathName();

klappt alles, mit "GetFileName" ebenfalls. Aber sowie ich auf die Dokumentenklasse schreiben will, Absturz. Warum das so ist? Keine Ahnung! Aber wenigstens kriege ich jetzt den Path.
Muß ich den Path eben über einen Umweg speichern, denn ich brauch ihn in der Dokumentenklasse.

Mfg

langer

 

[langer1801]

Eigentlich könnte ich den Thread jetzt schliessen. Denn warum die funktionsübergreifende Speicherung nicht klappt, ist zwar interessant - aber zu umgehen. Eine Frage hab' ich aber noch. Codeschnipsel:

	CButton *pBtn=(CButton*)GetParent()->GetDlgItem(IDOK);
	if(pDoc->sTitelstring=="Patient importieren")
		pBtn->SetWindowText("Importieren");
	else
		pBtn->SetWindowText("Exportieren");

Wenn ich den Dialog als Öffnen-Dialog nutze, klappt das auch, statt "Öffnen" wird die Schaltfläche mit dem Text "Importieren" angezeigt. Wenn ich ihn als Speicher-Dialog nutze, klappt das nicht. Es wird als Text weiterhin "Speichern" angezeigt. Hat der "Speichern"-Button vielleicht eine andere ID? Leider Habe ich nirgends etwas darüber gefunden, wird immer nur der Rückgabewert genannt - und der ist IDOK.

Mfg

langer

 

[langer1801]

Hi,
habs nun endlich mit Hilfe anderer Groups rausbekommen. Ursache, daß die Methode nicht klappt, ist der Umstand, daß intern die Beschriftung des Buttons geändert wird, wenn man auf einen Ordner klickt (Öffnen) oder ein File (Speichern). deshalb wird der eigene Text überschrieben. Mit dem folgenden Code klappt alles.

	if(pDoc->sTitelstring=="Patient importieren")
		this->SetControlText(IDOK,_T("Importieren"));
	else
		this->SetControlText(IDOK,_T("Exportieren"));

Mfg

langer