Appel d'une methode de classe par message inopérant dans une dll

Version imprimable

Bonjour,

je développe une dll qui a besoin d'être appelée par une fonction externe (dll SimConnect).
J'ai pris le choix de gérer les appels par messages du style WM_USER + xxx.

Mon problème est que la méthode de ma classe n'est jamais appelée. Je pense que ça viens du handle de ma dll ou du principe d'une dll qui bloquerai ce genre de chose... je suis :calim2:

ci dessous le code de la dll et quelques explications. Pour info je charge la dll dynamiquement

Si quelqu'un arrive à m'expliquer pourquoi cela ne marche pas ce serait cool,

merci

Jacques
--------------------
J'ai créé la classe suivante:
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 const WM_USER_EFBCONNECT = WM_USER + 3; type TEfbConnect = class procedure EfbConnectMessage(var Message: TMessage); message WM_USER_EFBCONNECT; private FpEventHandler: PEfbConnEventHandler; public end; ... procedure TEfbConnect.EfbConnectMessage(var Message: TMessage); begin SimConnect_CallDispatch(hSimConnect, DispatchHandlerFSX, nil); end;
hSimConnect est un handle fourni par la SDK de FSX (FlightSimulator X)
DispatchHandlerFSX est une procédure de ma dll appelée par le dispacher du SDK FSX

Pour initialiser le processus d'appel, j'utilise la commande suivante:

Code:

Result := SimConnect_Open(hSimConnect, 'Request Data', HandleModule, WM_USER_EFBCONNECT, 0, 0);

hSimConnect est différent de 0 quand un handle est fourni,
HandleModule est le handle de ma dll (sinon de la form quand le code est placé dans un programme).

Le handleModule est initialisé avec la ligne suivante:

Code:

HandleModule := GetModuleHandle(AnsiString('efbconnect.dll'));

Si je compare la valeur de HandleModule et du handle retourné par

Code:

hEfbConnect := LoadLibrary(dllName);

j'ai la même chose.

09/08/2010, 13h30
Jacques Deyrieux

Bon en fait j'ai trouvé d'où venais le pb!

a) Windows a besoin d'un handle d'application pour enregistrer et traiter un message et un listener.
b) Seule une méthode de class peut être définie avec un message WM_USER
c) Delphi implemente dans un classe objet un listener par défaut

Hors une dll semble ne pas être une application à proprement parler.

Assemblez tout ça et ça donne :
=> une classe qui créé un handle windows dans son constructeur,
=> un enregistrement du listener avec le handle créé
=> la méthode WndProc surchargée pour dériver les messages WM_USER... vers la bonne méthode,
=> un destructeur qui libère le handle à la fermeture de la dll.

bon je rajoute les bouts de code qui vont bien et voilà :ccool:

Jacques
09/08/2010, 14h15
ShaiLeTroll

Peux-tu utiliser PostThreadMessage pour appeler la DLL
car dans ce cas, tu lance un thread dans la section initialization de ta DLL, et tu boucles sur WaitMessage et GetMessage !

Voir dans le Code du TTimer, il contient lui aussi la création d'un contrôle uniquement pour l'écoute des messages hors d'une application, comme pour un Service par exemple !

Salut,

merci pour ta réponse je vais regarder plus tard si cela est plus pertinent, en attendant, ci dessous le code que j'ai réalisé et qui marche bien

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
const
 WM_USER_EFBCONNECT                    = WM_USER + 3;
 
type
  TEfbConnect = class
  private
    FpEventHandler: PEfbConnEventHandler;
  protected
     FWinHandle: HWND;
     procedure WndProc(var msg: TMessage);
  public
    constructor Create;
    destructor Destroy; override;
  end;
......
procedure DispatchHandlerFSX(pData: PSimConnectRecv; cbData: DWORD; pContext: Pointer); far; stdcall;
begin
  // Handle the various types of message
  case TSimConnectRecvId(pData^.dwID) of
    SIMCONNECT_RECV_ID_OPEN:
      begin
        RecvOpenData := PSimConnectRecvOpen(pData);
        checkFSXVersion;
      end;
    SIMCONNECT_RECV_ID_EVENT:
 
......
 
end;
 
......
 
procedure EfbConnectMessage(var Message: TMessage); far; stdcall;
begin
  SimConnect_CallDispatch(hSimConnect, DispatchHandlerFSX, nil);
end;
......
constructor TEfbConnect.Create;
begin
  Inherited;
  FWinHandle := AllocateHWND(WndProc);
end;
 
destructor TEfbConnect.Destroy;
begin
  DeallocateHWnd(FWinHandle);
  inherited;
end;
 
procedure TEfbConnect.WndProc(var msg: TMessage);
begin
  if Msg.Msg = WM_USER_EFBCONNECT then
    EfbConnectMessage(Msg);
 
  // call default proc
  Msg.Result := DefWindowProc(FWinHandle, Msg.Msg, Msg.wParam, Msg.lParam);
end;
 
{ dll handler for dynamic load }
procedure DLLHandler(Reason: integer); local;
begin
  case Reason of
    DLL_PROCESS_ATTACH:
      begin
        hSimConnect := 0;
        ExitCode := 0;
        HandleModule := HInstance;
        OpenSimConnect;
        // create efbconnect object
        cEfbConnect := TEfbConnect.Create;
      end;
    DLL_PROCESS_DETACH:
      begin
        { disconnect fsx }
        if IsSimConnectInitialized then
        begin
          CloseSimConnect;
          FreeAndNil(cEfbConnect);
        end;
      end;
  end;
end;
 
begin
{$IFDEF Debug}
  { True means Delphi checks &amp; reports memleaks }
  ReportMemoryLeaksOnShutdown := DebugHook <> 0;
{$ENDIF}
  { Make the Memory-Manager aware that this DLL is used in Thread-environments }
  IsMultiThread := true;
 { use dll handler for track dynamic attachments }
  DllProc := @DLLHandler;
  DllProc(DLL_PROCESS_ATTACH);
 
end.

voilà, no problem, mes messages sont bien reçus, par mon listener puis l'appel à au Dispatch de SimConnect fonctionne nickel.

Je pense que mon code n'est peut-être pas full multithread ready ;), si tu as des liens vers de la documentation donnant les règles à ne pas enfreindre, genre déclaration des variables dans la dll et autre subtilité, c'est top,

a+

Jacques