CFileDialog öffnet unter Umständen nicht

Ein Problem bei einem Kunden hat mich ins ungläubige Staunen getrieben.
Wir haben in einem Einstellungsdialog ein Edit Control für einen Dateinamen. Dazu einen simplen Schalter mit dem man einen CFileDialog öffnet und die Datei so auswählen kann. Bei einem Kunden wollte aber der Dialog in einigen Fällen nicht öffnen, der Klick auf den Schalter blieb ohne Wirkung. Da der entsprechende Code so simpel war, kam ein Programmfehler kaum in Frage.

Nachdem ich mir einen Screenshot habe senden lassen, staunte ich nicht schlecht, denn ich konnte den Fehler mit gleichen Eingaben zuerst nicht nachvollziehen, denn ich nutzte Vista und der Kunde hatte XP SP2. Sobald ich aber unter XP die selben Vorgaben machte, trat der Fehler auch bei mir auf.

Es scheint ein Bug in den Common Dialogs zu sein. Ist der Dateiname, den man im zweiten Parameter von CFileDialog angibt (vorschlägt) in bestimmter Weise „ungültig“, dann öffnet der Dialog nicht. Der Rückgabewert ist IDCANCEL (2) und CommDlgExtendedError liefert FNERR_INVALIDFILENAME. Ungültig ist aber fast zu viel gesagt, denn der Pfad enthielt an einer Stelle nur einfach 2 Backslashes statt einen, wie üblich.

Einfach nachzuvollziehen mit dem folgenden Snippet:

// Preset filename with a double backslash in the path:
// C:\TEMP\\Schrott.txt
CFileDialog dlg(TRUE,_T("txt"),_T("C:\\TEMP\\\\Schrott.txt"),
            OFN_HIDEREADONLY | OFN_OVERWRITEPROMPT,
            _T("Text files|*.txt|All files|*.*||"));
INT_PTR iResult = dlg.DoModal();
DWORD dwLastError = GetLastError();
DWORD dwCommLastError = CommDlgExtendedError();

CString strResult;
strResult.Format(_T("Returncode %d, Lasterror 0x%08X, CommLastError 0x%08X"),
            iResult,dwLastError,dwCommLastError);
AfxMessageBox(strResult);

Eigentlich nur verwunderlich, denn der Name selbst mit doppelten Backslashes wird vom Dateisystem sonst überall akzeptiert. Man kann eine Datei mit dem Namen öffnen, lesen und schreiben. Nur CFileDialog mag ihn nicht. Oder besser der Standard-Common-File-Dialog mag ihn nicht.

Bleibt die Frage warum ich unter Vista den Fehler nicht bekam?

Nutzt man VS-2008 und lässt das Programm unter Vista laufen, dann ist auch alles wieder gut. Denn unter Vista benutzt Der CFileDialog ein neues Interface (Common Item Dialog) und nicht mehr den normalen Common-File-Dialog. Die neuen in die MFC gewrappten Dateidialoge von Vista können mit dieser Vorgabe umgehen.
Lässt man das gleiche Programm wieder unter XP SP2 laufen, bekommt man den entsprechenden Fehler wieder, da in diesem Fall wieder die Standard-Common-Dialoge verwendet werden.

External Tools in VS-2005 IDE begrenzt die Argumente auf 251 Zeichen

Wenn man sich ein eigenes Tool baut, dann kann man Überraschungen erleben, wenn nicht das passiert was man möchte.

Auffällig ist schon, dass der Eingabebereich nicht sonderlich lange Befehlszeilen zulässt. Bei 251 Zeichen ist Schluss. Aber wirkliche Überraschungen erlebt man, wenn man Environment-Variablen oder die schönen vordefinierten Makros für den aktuellen Projektpfad verwendet. Wird hier eine etwas komplexere wirklich lange Befehlszeile aufgebaut, dann ist das Ergebnis oft genug zufällig.

Das Problem ist, dass alle Argumente der Befehlszeile auch nach dem Expandieren der Makros eine Länge von 251 Zeichen nicht überschreiten. Der Rest wird einfach abgeschnitten!

So werden z.B. Dateien kopiert, aber nichtdahin wo man sie hin haben wollte.

Good News: Diesen Bug hat man in VS-2008 gefixt. Die Eingabezeile für Argumente ist zwar immer noch begrenzt, aber Makros werden jetzt korrekt expandiert und die entsprechende Befehlszeile darf jetzt länger werden.

Patch für CPropertyPage Bug der MFC71.DLL/MFC71U.DLL

Wer keinen neuen Build bezüglich des dieses Problemes Bug in der MFC71.DLL bzgl. CPropertySheet/CPropertyPage machen kann oder auch nicht seinen Sourcecode nach entsprechenden Konstruktoren durchsuchen kann und auf die ausgelieferten Versionen von Microsoft angewiesen ist, kann auch einen kleinen Patch durchführen.

MFC71.DLL aus SP1 Version 7.10.6030
Größe 1.060.864 Bytes, Dienstag, 11. Juli 2006, 18:43:32
Patch der Adressen
0x0008E9F0 von 0x89 0x38 -> 0x90 0x90
0x0008EA09 von 0x89 0x38 -> 0x90 0x90

MFC71U.DLL aus SP1 Version 7.10.6030
Größe 1.056.768 Bytes, Dienstag, 11. Juli 2006, 19:02:30
Patch der Adressen
0x000A1ACC von 0x89 0x38 -> 0x90 0x90
0x000A1AE5 von 0x89 0x38 -> 0x90 0x90

Gesucht werden kann auch nach der Sequenz 0x8B 0x46 0x74 0x89 0x38. Diese Sequenz kommt in der MFC.DLL genau zweimal vor.

Es entspricht dem folgenden Code:

8B 46 74 mov eax,dword ptr [esi+74h]
89 38 .. mov dword ptr [eax],edi

Weggepatch wird in diesem Falle einfach das Laden der Adresse (zweites mov Statement) und durch zwei NOP ersetzt.
Wer die entsprechende PDB Datei hat sieht im Disassembly hier das Statement
m_psp.dwSize = sizeof(m_psp);
Der Bug befindet sich in der Datei dlgprop.cpp in den Zeilen 184 und 189!

Anwendung auf eigene Gefahr!

Bug in der MFC71.DLL bzgl. CPropertySheet/CPropertyPage

Ich habe ein Projekt, dass einen eigenen MFC Build verwendet. Dieser basiert zu 99,999% auf dem MFC71 SP1 Build aus VC-2003.NET. Das dies ein eigener Build ist spielt für den Bug allerdings keine Rolle, allerdings evtl. für die Lösung.

Zu den Rahmenbedingungen. Man baut eine EXE/DLL mit folgenden Eigenschaften:

  • _WIN32_IE< =0x0500.
  • Verwendet die DLL-Version der MFC (Use MFC in a Shared DLL)
  • Man verwendet CPropertyPage und CProprtySheet als Wizard.
  • Man verwendet Header-Titel und Header-Subtitel und damit einen der beiden nachfolgenden Konstruktoren:
    CPropertyPage(UINT nIDTemplate, UINT nIDCaption, UINT nIDHeaderTitle, UINT nIDHeaderSubTitle = 0, DWORD dwSize = sizeof(PROPSHEETPAGE));
    CPropertyPage(LPCTSTR lpszTemplateName, UINT nIDCaption, UINT nIDHeaderTitle, UINT nIDHeaderSubTitle = 0, DWORD dwSize = sizeof(PROPSHEETPAGE));

Die MFC71.DLL ist so gebaut, dass sie mit allen 3 Versionen der PROPSHEETPAGE Struktur klar kommen soll. Es gibt drei Versionen, die mit folgenden _WIN32_IE Definitionen unterschieden werden:

  • für WIN32_IE<0x0400, die aller erste Version die mit Windows 95 kam. Größe 40 Bytes.
  • für WIN32_IE>=0x0400 && _WIN32_WINNT<=0x0500, hier wurden Titel und Subtitel hinzugefügt (pszHeaderTitle, pszHeaderSubTitle). Größe 48 Bytes.
  • und zuletzt _WIN32_WINNT>=0x0501, hier kam noch ein Activation-Context dazu (hActCtx). Größe 52 Bytes.

Was passiert nun:

  • Einer der genannten Konstruktoren für die CPropertyPage wird aufgerufen.
  • Der letzte Parameter sizeof(PROPERTYPAGE) zeigt nun der DLL an welche Version das aufrufende Programm verwendet, damit die MFC71.DLL die entsprechenden Größen bereitstellt.
  • AllocPSP wird entsprechend aufgerufen und dynamisch diese PROPERTYPAGE allokiert.

Bis hierher ist alles prima, aber leider passiert es un, dass diese vordefinierte Größe in der Funktion CommonConstruct(LPCTSTR lpszTemplateName, UINT nIDCaption, UINT nIDHeaderTitle, UINT nIDHeaderSubTitle) überschrieben wird (Zeile 184+189 in dlgprop.cpp). Das passiert mit dem Statement:
m_psp.dwSize = sizeof(m_psp);
D.h. die PROPERTYPAGE Struktur ist mit weniger als 40 oder 48 Bytes allokiert. Im dwSize Member steht aber nun 52.
In der Funktion BuildPropPageArray() wird nun aus den einzelnen PROPERTYPAGE’s ein Array gebildet. Dabei werden jeweils dwSize-Bytes (also 52) aus den entsprechenden allokierten Bereichen kopiert. Aber Achtung, diese sind kleiner allokiert (40 oder 48 Bytes)
In der Debug Version ist das oft nicht tragisch, denn da kommen hinten dran noch einige Füllbytes. Auch in der Release Version kracht es nur manchmal. Genau nur dann, wenn einer der allokierten PROPERTYPAGE Strukturen genau auf mit einer allokierten Speicherseite endet und das 49ste Byte der Struktur eben nicht allokiert ist und die Speicherseite exakt hier endet.

Diese sehr üble Konstellation machte es mir extrem schwer diesen Fehler zu finden. Ich hasse es einfach optimierten Code zu debuggen 😉

Fix:

  • Keinen der obigen Konstruktoren verwenden und die Member m_strHeaderTitle und m_strHeaderSubTitle selbst füllen.
  • oder wie ich einen eigenen MFC Build erzeugen und verwenden. Die entsprechenden Code Zeilen 184+189 aus der dlgprop.cpp entfernen.

Hinweis:
Crashdumps zeigen meistens im Stacktrace die Funktionen BuildPropPageArray und memcpy!

BTW:
Dieser Bug betrifft sowohl die MFC71.DLL im RTM und im SP1.
In der MFC 8.0 des VS-2005 ist dieser Bug behoben.

Der # operator im RC-Compiler arbeitet inkonsistent

Heute ist mir ein übler Fehler des Ressourcen Compilers untergekommen.

Beabsichtigt war es einen #define in einen Text umzuwandeln, der als Ressourcen-String abgelegt wird.

Das ganze wurde so implementiert:

#define _MYSTRING(x)   #x
#define MYSTRING(x)    _MYSTRING(x)
STRINGTABLE
BEGIN
4713 MYSTRING(0409)
4714 MYSTRING(040E)
END

Alles kein Geheimnis, nur macht der Ressource-Compiler was er will. Der erste String wird korrekt angelegt. Beim zweiten wird wie durch Zauberhand noch eine 0 angehängt.

Das ganze Problem konnte ich auf allen VS-Systemen (VS2003, VS2003SP1, VS2005 und VS2005 SP1) nachvollziehen.

Gemeldet für Microsoff-Feedback unter:
https://connect.microsoft.com/VisualStudio/feedback/ViewFeedback.aspx?FeedbackID=252616