lpfnHook absturz als eigenständige exe

[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