lpfnHook absturz als eigenständige exe

[EWeiss]

Wenn ich die Anwendung mit Delphi kompiliere gibt es kein Problem.
Lasse ich sie innerhalb der IDE laufen gibt es keine Probleme.
Wenn ich diese aber normal starte stürzt die Anwendung beim beenden ab.

Was muss ich besonders beachten wenn ich den Hook für OpenDialog verwende.
Ohne das ich den OpenDialog starte gibt es keine Abstürze.

Der Hook.

Delphi-Quellcode:

ofn.lpfnHook := @DialogHookProc;

Die Flags.

Delphi-Quellcode:

ofn.Flags := OFN_EXPLORER
{ or OFN_ALLOWMULTISELECT } or OFN_FILEMUSTEXIST or OFN_HIDEREADONLY or OFN_PATHMUSTEXIST or
OFN_ENABLEHOOK

Übergabe der Subclass.

Delphi-Quellcode:

    WM_NOTIFY:
      begin
        case (POFNotify(lp)^.hdr.code) of
          CDN_INITDONE:
            begin
              DlgHandle := GetParent(WinHandle);
              SubClass(DlgHandle);

Die Subclass.

Delphi-Quellcode:

procedure SubClass(WinHandle: HWND);
begin

  FClientInstance := MakeObjectInstance(clProc.ClientWndProc);

  FPrevClientProc := Pointer(GetWindowLong(WinHandle, GWL_WNDPROC));
  SetWindowLong(WinHandle, GWL_WNDPROC, Integer(FClientInstance));
end;

procedure UnSubClass(WinHandle: HWND);
begin

  SetWindowLong(WinHandle, GWL_WNDPROC, Integer(FPrevClientProc));
  FreeObjectInstance(FClientInstance);
end;

Durchschleifen der Messagen.

Delphi-Quellcode:

procedure TClientWndProc.ClientWndProc(var Message: TMessage);
begin
  with Message do
  begin
    case Msg of
      WM_NOTIFY:
        Result := DialogHookProc(DlgHandle, Integer(Msg), Message.WPARAM, Message.LPARAM);
      WM_DRAWITEM:
        Result := DialogHookProc(DlgHandle, Integer(Msg), Message.WPARAM, Message.LPARAM);
      WM_PARENTNOTIFY:
        Result := DialogHookProc(DlgHandle, Integer(Msg), Message.WPARAM, Message.LPARAM);
    end;

    if (Result = 0) then
      Result := CallWindowProc(FPrevClientProc, DlgHandle, Msg, WPARAM, LPARAM)

  end;
end;

Subclass beenden.

Delphi-Quellcode:

  if IsOpenDialog then
  begin
    if GetOpenFileName(ofn) then
    begin
      Result := True;
      FileName := StrPas(szFile);
    end;
    SkinEngine.DestroyWindowResource(SKDialogHandle);

    if Windows.DestroyWindow(SKDialogHandle) then
      Windows.UnRegisterClass(wc.lpszClassName, hInstance);

    UnSubClass(DlgHandle);
    DlgHandle := 0;
    hDefview := 0;
  end

Ich wüste jetzt nicht was da falsch läuft das es als eigenständige Anwendung zum Absturz kommt.

EDIT:
Habe jetzt mal zum testen die CommDlg eingebunden (vielleicht liegt es an der eigens zusammengestellten TOpenFilename)
Aber nein mit oder ohne Hook die Anwendung stürzt ab. (aber nicht in der IDE)
Seltsames Problem.

gruss

[jaenicke]

An welcher Stelle stürzt die Anwendung denn ab? Wie sieht der Stacktrace aus?

[EWeiss]

Zitat:

Zitat von jaenicke (Beitrag 1349118)

An welcher Stelle stürzt die Anwendung denn ab? Wie sieht der Stacktrace aus?

Wie soll ich den ermitteln wenn innerhalb der IDE kein Fehler auftritt?
Die Anwendung stürzt nur als eigenständige EXE ab.
Und das auch nur dann wenn der Dialog aufgerufen wurde.

Windowslog meldet das ich einen Speicher freigeben will wo ich keine Berechtigung zu habe.
Ausnahmecode: 0xc0000005

Nur warum meldet der Compiler nichts so das ich den Fehler eingrenzen kann.

seltsam jetzt hat der Compiler einmal gemeckert.
Siehe Shot.
Nur wie soll ich jetzt das Objekt finden? LOL
Kann er den OpenDialog nicht freigeben ?

gruss

[ConnorMcLeod]

Probier mal MadExcept einzubinden. Dessen Fehlermeldungen sind aussagekräftiger.

[EWeiss]

Zitat:

Zitat von ConnorMcLeod (Beitrag 1349127)

Probier mal MadExcept einzubinden. Dessen Fehlermeldungen sind aussagekräftiger.

Jo denke das wäre die beste Lösung..
Das ist wohl wieder so ein Problem das man letztendlich nur selber lösen kann.

Dachte nur jemand hätte da ne Idee bzgl. des Hooks (ob man da etwas spezielles berücksichtigen muss) und der Weiterleitung der Messagen.
Denke aber das sollte eigentlich so in Ordnung sein.
Den Hook setze ich beim beenden einfach auf NIL denke das sollte reichen.

Was aber auch seltsam ist das Fenster wird geschlossen auch mit Winspector Spy kann ich das selbst bestätigen das da nichts mehr ist.
Frei doch nicht frei ?

gruss

[jaenicke]

MadExcept und Eurekalog können gute Fehlerlogs dazu erzeugen. Ein solches Log kannst du natürlich gerne hier anhängen, wenn du dort nichts sehen solltest.

Außerdem kannst du FastMM einbinden, denn wenn es wirklich ein Problem bei der Freigabe eines Objekts gibt, sollte das dort gemeldet werden.

[EWeiss]

Zitat:

Eurekalog können gute Fehlerlogs dazu erzeugen

Das schon mal nicht ;)
Kommt anscheinend mit Nonvcl nicht zurecht.

Die Anwendung stürzt ab keine Meldung die Anwendung hängt keine Meldung nichts.
MadExcept das gleiche keine Meldung nix.

Die einzige Meldung die ich bekomme ist diese im Anhang.
Damit kann ich aber im Moment mal leben.

gruss

[hoika]

Hallo,
tja, doof ;)

Hast du Units mit finalization-Code ?

Wenn ja, muss du das halt per
- MessageBox
- Log-File debuggen

[EWeiss]

Delphi-Quellcode:

Hast du Units mit finalization-Code ?

yep eine.
Das Problem ist nur wenn ich debugge beim beenden der Anwendung geht er nicht
in die finalization dieser Unit hinein.

gruss

[EWeiss]

Hmmm habe das Problem gefunden zumindest schon mal eins.

An die Leute die es vielleicht wissen.
Ich habe zu meiner OpenSaveFileDialog function die variable SkinConfig noch mit eingebaut so kann man von außen den Pfad zum aktuellen Skin übergeben.

Delphi-Quellcode:

function OpenSaveFileDialog(SkinConfig: string; ParentHandle: THandle; const DefExt, Filter, InitialDir,
  Title: WideString; var FileName: WideString; IsOpenDialog: Boolean): Boolean;
var
  ofn: TOpenFilename;
  szFile: array [0 .. MAX_PATH] of Char;
begin
  Result := False;
  //SkinConfigFile := SkinConfig;

  FillChar(ofn, SizeOf(TOpenFilename), 0);
  with ofn do
  begin..

Sobald ich jetzt

Delphi-Quellcode:

//SkinConfigFile := SkinConfig;

aktiviere. Also aus kommentiere stürzt die Anwendung als eigenständige EXE ab.

Warum ?
Habe ich noch nie erlebt.
Wohlbemerkt der NORMALE Dialog ohne irgendeine Veränderung mit und ohne Hook.

Die Funktion "OpenSaveFileDialog" kann ich doch benennen und ändern wie ich will da diese keinen Bezug zu TOpenFilename hat
also dementsprechend auch den Sitz davon nicht verändert.
Trotzdem kracht es. Hab jetzt 2 Tage gebraucht um den Mist zu finden. :wall::wall:
Keiner der Fehlerreport Tools konnte das ausmachen.

gruss