Fehler bei Dialog in dll

[snook]

hallo,

ich habe ein pluginsystem gebaut, dass dlls verwendet. wenn ich nun in einem plugin (aus der dll heraus) ein formular erzeuge läuft alles wunderbar. jetzt will ich jedoch in diesem formular auch noch einen TOpenDialog anzeigen lassen. Dabei krachts dann, und zwar, und das finde ich merkwürdig, erst nach einer gewissen zeit. zum besseren verständnis:

mainform verwaltet plugins
- plugin wird aus dll geladen
- zur kommunikation dll <-> mainform bekommt plugin ein botschaften-handle zugeteilt
- in einem plugin wird nun ein opendialog erzeugt

der dialog wird normal angezeigt. nach ein paar sekunden werden dann irgendwelche module ent- und geladen (erkennt man im ereignisprotokoll). dann erscheint im ereignisprotokoll die meldung, dass das thread des hauptformulars beendet wurde.
und dann erscheint als fehlermeldung
---------------------------
Benachrichtigung über Debugger-Problem
---------------------------
Im Projekt D:\delphi\PluginSystem\Test\Project2.exe sind zu viele auseinanderfolgende Exceptions aufgetreten: ''access violation at 0x8b045389: read of address 0x8b045389''. Prozess wurde angehalten. Mit Einzelne Anweisung oder Start fortsetzen.

ich hoffe ihr könnt damit irgendetwas anfangen.

edit\\
falls es jemandem hilft, das letzte was im ereignisprotokoll vor dem absturz des hauptthread steht ist
Modul laden: UNKNOWN_MODULE_145. Ohne Debug-Infos. Basisadresse: $01ED0000. Prozess Project2.exe (5088)
Modul laden: PDFShell.DLL. Ohne Debug-Infos. Basisadresse: $01D60000. Prozess Project2.exe (5088)
Modul laden: MSVCR80.dll. Ohne Debug-Infos. Basisadresse: $78130000. Prozess Project2.exe (5088)
Modul laden: UNKNOWN_MODULE_146. Ohne Debug-Infos. Basisadresse: $01DE0000. Prozess Project2.exe (5088)
Modul laden: shimgvw.DLL. Ohne Debug-Infos. Basisadresse: $5CE90000. Prozess Project2.exe (5088)
Modul laden: gdiplus.dll. Ohne Debug-Infos. Basisadresse: $4EBA0000. Prozess Project2.exe (5088)
Thread-Start: Thread-ID: 1148. Prozess Project2.exe (5088)

[snook]

keine antwort is nicht gut. ich habe das problem jetzt soweit eingegrenzt, dass es irgendwie mit der botschaftenverarbeitung zusammenhängt, wenn er die WM_ACTIVATEAPP message sendet. das problem ist, weiter bin ich noch nicht gekommen. ich habe in jedem plugin, dass via AllocateHWnd erzeugt wird als letzte möglichkeit, wenn die botschaft nciht verarbeitet wird einen defwindowproc aufruf. dabei übergebe ich als handle das zum plugin gehörende MsgHandle. mehr zur verarbeitung passiert aber auch nicht. muss ich evtl noch etwas anderes berücksichtigen???

[chaosben]

Versuch mal, beim Dialog.Execute das Handle des (Haupt)formulars zu übergeben.

[snook]

hee, danke für den tip, hab jetzt alles durchprobiert. weder hInstance der main, noch der zugehörigen dll haben funktioniert. application.handle auch nicht und form.handle des hauptformulars auch net. bin langsam etwas verzweiflet, weil ich jetzt alle windowsprocs die ich definiert habe noch mal durchgerannt bin um zu schauen ob nicht doch irgendwo die messages hängenbleiben, aber sie werden brav bis zu meinen basisklassen durchgereicht, in denen dann die defwindowproc aufgerufen wird. habe gerade gelesen, dass es noch für dialoge ne defdlgproc funktion gibt, weiß aber ehrlich gesagt net wie ich die einsetzen soll, also wie ich erkennen soll, ob die zu verarbeitende botschaft nun gerade von nem dialog kommt. falls es jemandem hilft, poste ich mal noch ein paar wichtige verarbeitungsprozeduren für die botschaften:

Delphi-Quellcode:

// windowproc der plugin basisklasse

procedure TCustomPlugIn.WndProc(var Msg: TMessage);
begin
  if (Msg.Msg > WM_PLUGIN) and (Msg.Msg <= CM_PLUGIN) then
    with Msg do
    begin
      case Msg of
        PM_EXECUTE   :
          begin
            run;
          end;
        PM_REGEVENT  :
          begin
            with PPlugInEvent(lParam)^ do
              RegisterNewEvent(name,EventID,Handle,lParam);
          end;
        PM_UNREGEVENT:
          begin
            with PUnRegisterEvent(lParam)^ do
              UnRegisterEvent(name,handle);
          end;
        PM_QUERYSTATUS: result := OrdToInt(Status);
        PM_RELEASE : PostMessage(PlugInManager,PM_RELEASE,MsgHandle,0);
        PM_GETPLUGIN: result := LongInt(IPlugIn(self));
        else
          Result := DefWindowProc(MsgHandle,Msg,WParam,LParam);
      end;
    end
  else
    Msg.Result := DefWindowProc(MsgHandle,Msg.Msg,Msg.WParam,Msg.LParam);
end;

//windowproc der wrapperklasse für TControl

procedure TControlWrapper.WndProc(var Msg: TMessage);
var Data: IControlData;
begin
  if Msg.Msg > WM_PLUGIN then
    with Msg do
      case Msg of
      PM_GETDATA:
        if Assigned(FControl) then
          begin
//          FCriticalSection.Acquire;
            try
              GetControlData(Data);
              IControlData(result) := Data;
            finally
              Data := nil;
//            FCriticalSection.Release;
            end;
          end;
        PM_SENDDATA:
          begin
//          FCriticalSection.Acquire;
            try
              Data := IControlData(lParam);
              if Assigned(Data) and supports(Data, IControlData) then
                SetControlData(Data);
            finally
              Data := nil;
//            FcriticalSection.Release;
            end;
          end;
        CM_CHANGELOCK: ControlLocked := not ControlLocked;
        CM_GETLOCKSTATE:
          if FControlLocked then
            result := 1
          else
            result := 0;
      end
  else
    Msg.Result := DefWindowProc(MsgHandle,Msg.Msg,Msg.WParam,msg.LParam);
end;

// so hängt sich der wrapper bei dem zugehörigen TControl im Hauptkontext ein
FOldWindowProc := FControl.WindowProc;
FControl.WindowProc := ControlWndProc;

procedure TControlWrapper.ControlWndProc(var Msg: TMessage);
begin
  FOldWndProc(msg);
    if (AllocatedPlugIn > 0) then
    begin
      with Msg do
        SendMessage(AllocatedPlugIn,msg,wParam,lParam);
    end;                      
end;

[snook]

okay, falls jemand mal mit windoesbotschaften und derren verarbeitung probleme hat, hab es gelöst. bin mir zwar immer noch nicht so ganz im klaren wie die botschaftsverarbeitung aussieht, aber so hab ich das ganze jetzt gehandelt.

Delphi-Quellcode:

procedure TControlWrapper.ControlWndProc(var Msg: TMessage);
var PlugIn: IPlugIn;
    addr  : LongInt;
    lMsg  : TMessage;
begin
  ControlLocked := true; // ordnet FControl wieder die original windowproc zu
  FControl.WindowProc(msg); // verarbeitung der message ohne weiteres einhängen der pluginbotschaftsverarbeitung
  ControlLocked := false; // hängt sich wieder in die windowproc von FCOntrol ein
    if (AllocatedPlugIn > 0) then // botschaft wird an das plugin gesendet um dort darauf zu reagieren
    begin
      addr := SendMessage(AllocatedPlugIn,PM_GETPLUGIN,0,0);
      if addr <> 0 then
        try
          PlugIn := IPlugIn(addr);
          with lMsg do
          begin
            msg := CM_NOTDISPNEXT;
            lParam := 0;
            wParam := 0;
            result := 0;
          end;
          PlugIn.WndProc(lmsg); //verhindert aufruf von DefWindowProc, falls botschaft von plugin nicht vearbeitet wird
          PlugIn.WndProc(Msg);
        finally
          PlugIn := nil;
        end;
    end;
end;

letztendlich lasse ich das control in ruhe seine botschaft verarbeiten, bis ich selber damit weiter rumpfusche. ausserdem wird die botshcaft nicht an die defwindowproc übergeben, da sie bereits in FControl verarbeitet wurde.
da es jetzt funktioniert schliese ich mal darauf, das bei der verarbeitung von globalen messages wohl in den delphi controls noch einiges mehr an botschaften traffic verursacht wird, obwohl ja die botschaften hier zur erzeugung des dialogs verwendet werden (scheinbar werden aber wohl die controls auch neu gezeichnet)