try - except in Dialogprozedur führt zu Darstellungfehler

[Niko]

Ich zeige in einem NonVCL-Projekt einen Dialog aus einer Ressourcendatei mit DialogBox(...) an. Das funktioniert auch ganz normal. Sobald ich aber in der zugehörigen Dialogprozedur einen Try-Except- oder Try-Finally-Block verwende, wird das Dialogfenster durchsichtig und ohne Titelleiste dargestellt , d.h. es sind nur die Steuerelemente zu sehen. Das ganze passiert unabhängig davon, ob der Try-Except-Block überhaupt durchlaufen wird oder nicht. (OS: Win98)
Hat jemand schon mal die selbe Erfahrung gemacht oder könnte das mal ausprobieren und schreiben, ob der Fehler bei ihm auch auftritt?

Vielen Dank

[Luckie]

Noch nicht getestet, noch nicht gesehen, noch nicht gemacht. Aber was hat ein try-finally Bloch in der Dialog-Prozedur verloren? Und wenn du da einen hast, ist dein Programm schlecht strukturiert.

[Niko]

Ich belege in der Dialogprozedur dynamisch Speicher zum Auslesen eines Edit-Feldes und wollte den gerne mit try-finally schützen. Dafür eine eigene Prozedur zu schreiben lohnt sich eigentlich nicht.

[choose]

Hallo Niko,

benutzt Du vielleicht gepatchte Units, ähnliche denen, die bei der KOL angeboten werden? Hier komm es beim Exceptionhandling mitunter zu merkwürdigen Randerscheinungen!

Eine bessere Antwort kann ich Dir leider nicht geben. Vielleicht, wenn Du den verursachenden Code postest?

[Luckie]

Zeig mal Code.

[Niko]

Erstmal Danke für die Antworten.

@choose:
Ich verwende nur Units, die mit Delphi geliefert werden.

Der Code der Dialogprozedur:

Delphi-Quellcode:

function DlgProc(hDlg: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM):
  Boolean; stdcall;
begin
  Result := true;
  case uMsg of
    WM_COMMAND:
      begin
        if LOWORD(wParam) = IDOK then
        begin
          try  // Wenn man diesen try-finally-Block entfernt, ist der Fehler weg.
            // Hier steht eigentlich Code, aber der Fehler tritt auch ohne auf.
          finally
            // Code
          end;      
          EndDialog(hDlg, 0);
        end;
      end;
  else
    Result := false;
  end;
end;

Ich hab mal eine Projektdatei, die den Fehler erzeugt, zusammen mit der verwendeten Ressourcendatei angehängt.

[Niko]

Da der Code ja immerhin schon zwei mal heruntergeladen wurde, trau ich mich noch mal nachzufragen: Könnte mal bitte jemand die oben angehängte dpr kompilieren und schreiben, ob das erzeugte Dialogfeld durchsichtig ist oder richtig angezeigt wird. Mich würde interessieren, ob der Fehler bei neueren Delphi-Versionen auch auftritt.

[Luckie]

Tja, ich habe den gleichen Effekt, wie du. Bin aber auch etwas ratlos.

[choose]

Hallo Niko,
sorry, dass ich erst jetzt antworte, hatte etwas viel um die Ohren...

Nachdem ich das Problem auf

Delphi-Quellcode:

function myDlgProc(hDlg: HWND; uMsg: UINT; wParam: WPARAM; lParam: LPARAM):
  Boolean; stdcall;
begin
  Result:= False;
    try
    finally
    end;
 case uMsg of
   123: p();
 end;
end;

eingrenzen konnte (das Case- und das Try-Statement sind notwendig!), wurde ich doch etwas stutzig und habe mir den produzierten ASM-Code einmal etwas genauer angesehen. Der Rückgabewert wird wie folgt gebildet:

Code:

  mov al, [ebp-$01]

In der Win32-Referenz steht zu DialogProc "[...] the dialog box procedure should return nonzero if it processes the message, and zero if it does not.", während in der Deklaration von einem Datentyp BOOL ausgegangen wird. Dies ist typische C-Manier, bei der die Programmierer tatsächlich fast ausschließlich von Ints ausgehen und die Typen nur geschaffen wurden, um hübsch auszusehen...

Tatsache ist nun, dass Delphi ein Boolean als Byte ansieht (trotzdem wg des ByteAlignment aber 4 Bytes beansprucht) und Deine DlgProc aus sicht des Compilers dann False ist, wenn das LowByte des LowWords von eax null ist (siehe snippet von oben)!

Durch den vorherigen Code (TryFinally, Case,...) ist der Akkumulator aber geändert worden, so dass mindestens eines der anderen Bits von eax gesetzt ist. Das API intepretiert diesen Wert (ungleich null) nun gemäß der Definition "Ungleich null heißt True" (siehe oben).

Wenn Du Den Rückgabewert von DlgProc auf LongBool änderst, geht auch der Compiler von einem bool'schen Wert aus, der 32 Bit breit ist, kompiliert den Rückgabewerte so

Code:

  mov eax, [ebp-$04]

und der Code sollte funktionieren.

[Niko]

Vielen Dank für die Antwort! Der Code funktioniert jetzt.
Alleine wäre ich nie auf den Fehler gekommen.