Discussion :

[sniperpro]

Bonjours les amis,

je voulais savoir es-ce que passer un paramètre de type TForm dans une procédure DLL, pose un problème ?

[Ph. B.]

Bonjour

Cf. la discussion suivante dans le forum Lazarus :
Problème d'affichage d'une fiche à partir d'une DLL

En gros, tant que ton exe et ta dll sont générés par la même version de l'outil de développement, il ne devrait pas y avoir de problème, Dans les autres cas, tu joues à la roulette russe.
En fait, il faut éviter de passer autre chose que des paramètres simples dans les procédures et fonctions exportées par une dll ou alors il faut utiliser des mécanismes à bases d'interfaces comme l' a indiqué Paul Toth dans le sujet référencé ci dessus.
--
Philippe.

[tourlourou]

tant que ton exe et ta dll sont générés par la même version de l'outil de développement, il ne devrait pas y avoir de problème

Sans rien en connaître, ne vaut-il pas mieux dans ce cas utiliser les paquets ?

[Ph. B.]

Sans rien en connaître, ne vaut-il pas mieux dans ce cas utiliser les paquets ?

Un paquet n'est rien d'autre qu'une dll. La remarque vaut pleinement.

Pour s'en rendre pleinement compte, il suffit d'essayer d'utiliser un paquet compilé pour Delphi 7 avec Delphi 2006+ et on verra apparaitre un message très similaire à :
"Ne peut charger le paquet VCL70. Il contient l'unité 'ToolsAPI' qui est également contenu dans le paquet VCL100"
--
Philippe

[ShaiLeTroll]

Lit ce sujet : DLL String Pourquoi ça marche sans BORLNDMM.DLL
C'était la première fois que je tentais du String et TForm sans BORLNDMM.DLL pour voir ce que cela fait (avant soit j'utilisais un Framework qui encapsulait cela, soit mes DLL étaient totalement indépendantes respectant un style "C")
On est supris de voir tout ce qui peu fonctionner sans BORLNDMM.DLL, en fait tant que l'EXE ne manipule pas directement l'objet de la DLL, ça passe
Si veux que l'exe modifie lui même l'objet de la DLL sans passer par des méthodes dédiées ShareMem\BORLNDMM.DLL ou FastShareMem, ou SimpleShareMem sont indispensables (cela dépend de ta version, D2 et D7, il me semble, ça va être DUR DUR !)

J'ai pratiqué l'échange de TForm, mais masqué !
En Delphi 6 : La DLL fourni un ensemble de procédures et types, utilise un paramètre qui contient un Pointer, la DLL sait que c'est une TForm, l'EXE n'en sait rien, il DOIT utiliser les procédures de la DLL pour l'utiliser,

En C++Builder 2007, la DLL fourni un interface (classe abstraite pure) avec un ensemble de méthode, idem toute manipulation passe par ces méthodes, la DLL est une boite noire !

Tant que tu respecte ce type de fonctionnement, tu n'auras pas de mauvaise surprise liée au partage d'objet


Sinon, si tu le peux fourni plutôt des Handles de Control !
Encore ton histoire de clavier et de DLL, tu n'as pas besoin de TForm (mais juste d'un AllocateHWnd
Relit la Réponse de AndNotOr !!!

Au boulot, on va essayer la roulette russe entre C++Builder 2007 et XE2, on va voir ce qu'il faut alléger pour faire cohabiter des BPL, DLL et EXE dans les deux versions qui échange des interfaces (ça c'est propre, j'utilise même des BSTR) mais une exception, j'ai passé un TWinControl pour ancrer des TForm de la DLL via la propriété Parent dans un Panel de l'EXE (l'effet étant nettement meilleur à _WINDOWS_::SetParent() pour la gestion du focus ...) et là c'est le suspens !
Et pour le reste de code, j'ai vu des horreurs, et j'ai peur sur la comparaison de nom de classe (d'un côté ShortString et de l'autre ... UnicodeString !)

[sniperpro]

Bonjour à vous tous,

je vous remercie pour vos suggestions.
Bon ya beaucoup à lire ce weekend, je vous tiendras au courant de l'histoire du clavier et de la DLL

[edam]

tu peut m'explique ce que ta dll va faire avec un paramétre type TForm???

[sniperpro]

Bonjour,

Bon pour le plaisir de edam :

j'en ai 2 procédures (je précise toujours, développées par AndNotOr), qui permettent de gérée un message WM_INPUT :

la première, prépare la structure d'enregistrement :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
procedure TFormTest.FormActivate(Sender: TObject);
var
  RawsList   :array of TRawInputDeviceList;
  RIDList    :array[0..0] of TRawInputDevice;
  RIDInfo    :TRidDeviceInfo;
  DeviceName :string;
  Count      :cardinal;
  Size       :dword;
  i          :integer;
 
begin
  //Détermine le nombre de device
  GetRawInputDeviceList(nil, Count, SizeOf(TRawInputDeviceList));
 
  if Count > 0 then
  begin
    //Récupère la liste des devices
    SetLength(RawsList, Count);
    GetRawInputDeviceList(@RawsList[0], Count, SizeOf(TRawInputDeviceList));
 
    for i := 0 to Count -1 do
    begin
      //Récupère le type du device
      Size := SizeOf(TRidDeviceInfo);
      RIDInfo.cbSize := Size;
      GetRawInputDeviceInfo(RawsList[i].hDevice, RIDI_DEVICEINFO, @RIDInfo, Size);
 
      //Ne concerve que les claviers
      case RIDInfo.dwType of
        RIM_TYPEKEYBOARD : begin
                             //Nom interne du device
                             GetRawInputDeviceInfo(RawsList[i].hDevice, RIDI_DEVICENAME, nil, Size);
                             SetLength(DeviceName, Size);
                             GetRawInputDeviceInfo(RawsList[i].hDevice, RIDI_DEVICENAME, @DeviceName[1], Size);
 
                             //Ne prend pas en compte les infos pour Terminal Server
                          //   if StartsStr('\??\Root', DeviceName) then Continue;
 
                             //Ajout à la liste (Object est rempli avec hDevice pour contrôle dans WM_INPUT)
                         //    CheckListBox1.AddItem(GetDeviceDesc(DeviceName), pointer(RawsList[i].hDevice));
                           end;
      end;
    end;
 
    //Tous actif par défaut
 //   CheckListBox1.CheckAll(cbChecked);
 
    //S'enregistre pour la réception des messages clavier
    RIDList[0].usUsagePage := $01;
    RIDList[0].usUsage     := $06;
    RIDList[0].dwFlags     := RIDEV_NOLEGACY;  //Ne génère pas WM_KEYDOWN, WM_KEYUP !!!
    RIDList[0].hwndTarget  := Handle;
 
    if not RegisterRawInputDevices(@RIDList[0], Length(RIDList), SizeOf(TRawInputDevice)) then
      RaiseLastOSError;
  end;
 
end;

La seconde, gére le WM_INPUT :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

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
procedure TFormTest.WMInput(var Message :TMessage);
var
  Data :PRawInput;
  Size :dword;
 // i    :integer;
 
begin
  Message.Result := 1 ;    //Spécifier la valeur retournée a windows en réponse à la gestion du WM_INPUT
 
  if Assigned(ActiveControl) then
  begin
    GetRawInputData(Message.LParam, RID_INPUT, nil, Size, SizeOf(TRawInputHeader));
    GetMem(Data, Size);
 
    if GetRawInputData(Message.LParam, RID_INPUT, Data, Size, SizeOf(TRawInputHeader)) = Size then
    begin
      //Est-ce un clavier ?.. (ça devrait, mais pour être sûr !)
      if Data.header.dwType = RIM_TYPEKEYBOARD then
      begin
 
     //   i := FormParam.CheckListBox1.Items.IndexOfObject(pointer(Data.header.hDevice));
 
 
        if Data.header.hDevice = 15794249 then
        begin
          //...oui => Traitement du WM_KEYDOWN
          if Data.keyboard.Message = WM_KEYDOWN then
            ActiveControl.Perform(WM_CHAR, Data.keyboard.VKey, 0);
 
          Message.Result := 0;
        end;
      end;
    end;
  end; // if Assigned(ActiveControl) then
end;

Je veux les mettres dans une DLL, pour les séparées de la fiche où je voulais faire la gestion de WM_INPUT