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

[Zacherl]

Wird irgendeine Heap/Stack-Corruption sein. Irgendwo eventuell die

Delphi-Quellcode:

stdcall

Calling-Convention vergessen?

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1349418)

Wird irgendeine Heap/Stack-Corruption sein. Irgendwo eventuell die

Delphi-Quellcode:

stdcall

Calling-Convention vergessen?

Ahhh wäre eine alternative werde das nochmal prüfen.

Danke.

EDIT:
Geprüft und tatsächlich ja.
Löst aber nicht mein Problem.

Öffentliche API. "SKAeroAPI" (Stellt den Eingang über den Ausgang der DLL bereit.)

Delphi-Quellcode:

function SKAERO_OpenSaveFileDialog(SkinConfig: string; ParentHandle: THandle;
  const DefExt, Filter, InitialDir, Title: WideString; var FileName: WideString;
  IsOpenDialog: boolean): boolean; stdcall; external dllfile;

Aufruf.

Delphi-Quellcode:

              
if SKAERO_OpenSaveFileDialog(DefSkin, WinHandle, '.mp3',
  'Mp3 Files (*.MP3|*.mp3', ParamStr(0),
  ' Open Media File', MainApp.Newfile, True) then
begin
  if MainApp.Newfile <> '' then
    MainApp.SampleAudioStream(MainApp.Newfile);
end;

Weiterleitung über meine Master Unit in der alle Exports verwaltet werden.
Die Rückgabe erfolgt dann von hier.

Delphi-Quellcode:

function SKAERO_OpenSaveFileDialog(SkinConfig: string; ParentHandle: THandle; const DefExt, Filter, InitialDir,
  Title: WideString; var FileName: WideString; IsOpenDialog: Boolean): Boolean; stdcall;
begin

  result := OpenSaveFileDialog(SkinConfig, ParentHandle,  DefExt, Filter, InitialDir,
    Title, FileName, IsOpenDialog);
end;

unit OpenFileDlg Verarbeitung der Funktionen
Global Im Header hier hatte ich stdcall vergessen.

Delphi-Quellcode:

function OpenSaveFileDialog(SkinConfig: string; ParentHandle: THandle; const DefExt, Filter,
  InitialDir, Title: WideString; var FileName: WideString; IsOpenDialog: Boolean): Boolean; stdcall;

Das eigentliche Arbeitspferd
Auch hier stdcall vergessen

Delphi-Quellcode:

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

Der Aufruf in meiner OpenSaveFileNameHook function

Delphi-Quellcode:

CDN_INITDONE:
  begin
  //......
  OpenDialog.PrepareWindow(DlgHandle, SkinConfigFile);
  //.....
  end;

Das war's

Auch mit stdcall es kracht als eigenständige EXE. :duck:
Ich muss mich verstecken das kann niemand mehr hören.

Lege ich anstelle von "SkinConfigFile" den Pfad Hardcoded an kein Absturz als EXE.
Ich hätte eine Lösung aber das behebt nicht das ursprüngliche Problem.
Ich möchte wissen warum ein einfacher String die Anwendung außerhalb der IDE abstürzen lässt.

gruss

[Zacherl]

Noch eine letzte Vermutung, dann bin ich auch mit meinem Latein am Ende:
Die anderen String Parameter deiner Funktion hast du als

Delphi-Quellcode:

const WideString

deklariert, den SkinConfig aber als normalen

Delphi-Quellcode:

String

. Das

Delphi-Quellcode:

const

schaltet indirekt den Ref-Count der String-Parameter aus, was bei SkinConfig aber nicht der Fall ist. Vielleicht gibt es da Probleme mit dem SharedMemory zwischen Dll und MainApp.

[EWeiss]

Zitat:

Zitat von Zacherl (Beitrag 1349455)

Noch eine letzte Vermutung, dann bin ich auch mit meinem Latein am Ende:
Die anderen String Parameter deiner Funktion hast du als

Delphi-Quellcode:

const WideString

deklariert, den SkinConfig aber als normalen

Delphi-Quellcode:

String

. Das

Delphi-Quellcode:

const

schaltet indirekt den Ref-Count der String-Parameter aus, was bei SkinConfig aber nicht der Fall ist. Vielleicht gibt es da Probleme mit dem SharedMemory zwischen Dll und MainApp.

Danke! Ich könnte das mal versuchen um festzustellen ob es daran liegt. (Aus Neugierde)

Der String Ansicht macht kein Problem..
Daher habe ich es jetzt anders gelöst.

Beim initialisieren der Engine muss ich ja den Default Pfad zur Skin Konfiguration angeben.

Delphi-Quellcode:

// Skin Initialisieren und einstellungen laden
SKAERO_InitSkin(MainHandle, DefSkin, True, True);

Da habe ich mir jetzt eine extra Property angelegt mit der ich diesen Pfad einlesen kann.

Delphi-Quellcode:

OpenDialog.PrepareWindow(DlgHandle, SkinEngine.SkinConfigFile);

Seit dem habe ich ruhe.

Jetzt geht es mit kompilierter exe und in der IDE..
Was aber nicht heißen soll das es mich nicht interessieren würde warum es nun nicht geht
wenn der Pfad bei OpenSaveFileDialog direkt mit übergeben wird.

Schon seltsam das ganze. ;)
Ich muss jetzt nur noch sehen wie ich die Farbe des SysListView32 verändern kann danach ist das für mich in Ordnung so.
Vielleicht mache ich noch ein AlbumCover in den Dialog.. mal sehn.
Aber das ist ein anderes Thema.

gruss

[Zacherl]

Zitat:

Zitat von EWeiss (Beitrag 1349457)

Zitat:

Zitat von Zacherl (Beitrag 1349455)

Noch eine letzte Vermutung, dann bin ich auch mit meinem Latein am Ende:
Die anderen String Parameter deiner Funktion hast du als

Delphi-Quellcode:

const WideString

deklariert, den SkinConfig aber als normalen

Delphi-Quellcode:

String

. Das

Delphi-Quellcode:

const

schaltet indirekt den Ref-Count der String-Parameter aus, was bei SkinConfig aber nicht der Fall ist. Vielleicht gibt es da Probleme mit dem SharedMemory zwischen Dll und MainApp.

Danke! Ich könnte das mal versuchen um festzustellen ob es daran liegt. (Aus Neugierde)

Ja, teste das mal. Würde mich auch interessieren :stupid: Einfach nur ein

Delphi-Quellcode:

const

davorsetzen, sollte das Problem beheben, wenn ich Recht habe.

[EWeiss]

Also was funktioniert ist "const WideString" bei "const string" oder "string" Kracht es.
Aber wie gesagt ich behalte jetzt meine geänderte Fassung dann muss sich der Anwender nicht um die Übergabe kümmern
zumal er das ja schon einmal beim initialisieren des Skins getan hat.

Was mich an der ganzen Sache ärgert das der Compiler das nicht erkennt und auch kein anderes Überwachungs-Tool.
Das hat mich jetzt ein paar Tage gekostet.

gruss

[EWeiss]

Ich denke das ich das erst mal nicht weiter verfolge mit dem OpenFileDialog.
Bin kein Informatiker oder Profi der so tief in das System eingreifen kann um den Dialog entsprechend anzupassen.
Es ist ein zu tiefer eingriff in das System und letztendlich ist das Ergebnis nicht so wie gewünscht.

Was soll's hab ja sonst nix zu tun.
Auf jeden fall wissen wir nun warum das Problem entstanden ist.

Nochmal einen Shot wie es jetzt aussieht das Problem ist nur das die Events irgendwie nicht so weitergeleitet werden
wie sie sollen nach dem eingriff ins System.
Leider findet sich niemand der da helfen könnte. ;)

gruss