Discussion :

[ALWEBER]

Je viens de faire une fonction addition dans l'activeX qui renvoit juste l'addition de deux nombres (sans lien avec la DLL Win32, juste pour voir si j'arrive à l'appeler depuis mon application .NET, et ça marche). Je repars donc sur l'encapsulation.

Attention! Qu'est ce qu'un activeX ? De manière simple c'est un programme qui s'exécute sur le poste du client généralement à l'intérieur d'une fenêtre windows. Donc ce programme aura besoin des dll requises sur le poste du client. Ce qui marche sur ton poste ne marchera pas forcément sur le poste de l'utilisateur final ! Comme tu débutes en .NET tu te pose les mêmes questions que nous nous sommes posés avec Delphi 8 NET et versions suivantes. Avant donc de débuter ton projet il convient de faire un état des lieux de ce que tu souhaites réaliser.

[ShaiLeTroll]

En fait ce n'est pas un ActiveX, c'est un terme honteusement galvaudé que j'utilise quand je parle d'un projet bibliothèques de types et que l'on met dedans un objet automation, j'utilise ce terme car je crée toujours mon objet automation dans un projet "Bibliothèque ActiveX"

Sinon, Jognu, comme je te l'ai dit, tu fois définir TCodeUtilisateur sous la forme d'une interface ICodeUtilisateur, comme je l'ai fait dans mon exemple pour TResultStruct et TResultStructImpl \ IResultStruct, avec une propriété ID par exemple de type WideString, ce que tu es en train de faire est une encapsulation complète, il est possible que certains objets soit différents ...

bon si dans ton cas, ce n'est qu'un shortstring, ne te complique pas la vie, utilise le type WideString partout ... mais cela se compliquera si tu veux faire évoluer ton TCodeUtilisateur dans la DLL, il te faudra repenser ton ActiveX ... donc en partout tout de suite sur une interface, tu laisses ouvert plus de porte ...

WideString (ou BSTR) n'est pas soumis au compteur de référence comme le serait le AnsiString (merci de confirmer ou d'infirmer si quelqu'un sait exactement), et donc ShareMem n'est pas utile, en tout cas, j'ai mis des WideString dans mes structures, et j'ai filé mes deux DLL (Win32 + Encapsulation ActiveX) et je n'ai pas du tout mis ShareMem, et l'utilisateur de ma DLL en VB.Net n'a pas de problème ...

Evidemment, mon exemple n'est que dans l'idée, ... je n'ai pas mis le détail du loadlibrary pensant que tu l'avais déjà fait ... dans mon ActiveX j'ai une unité qui est dédié à charger les fonctions, cela donne ... je voudrais pas dire, mais tu as j'espère déjà fait de liaison dynamique de DLL en Win32 ??? Car si tu n'en as pas fait, j'ai l'impression qu'on tourne en rond ...

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
59
60
61
62
unit Shai_Header;
 
interface
 
uses ...
 
function ShaiFunction(const lpParam: TParamStruct): TResultStruct; 
function AutreFunction(Truc: PChar): TResultStruct; 
 
 
implementation
 
var
  APIHandle: THandle = 0;
  APIFunctions: record
    _ShaiFunction: function(const lpParam: TParamStruct): TResultStruct; stdcall; // tu note _ !
    _AutreFunction: function(Truc: PChar): TResultStruct; // j'en ai tout un tas ...
  ...
  end;
 
// la fonction magique qui charge tout mes fonctions
procedure InitFunction(const FunctionName: string; var FunctionHandle: Pointer);
var
  ModuleFileName: string;
begin
  if FunctionHandle = nil then
  begin
    if APIHandle <= 0 then
    begin
      ModuleFileName := ExtractFilePath(WindowsEx.GetCurrentModuleFileName()) + '***.dll';
      APIHandle := LoadLibrary(PChar(ModuleFileName));
    end;
 
    if APIHandle > 0 then
    begin
      FunctionHandle := GetProcAddress(APIHandle, PChar(FunctionName))
    end
    else
    begin
      raise EOleExceptionShai.Create(ERR_MAPPING_COM_API_NOT_FOUND);
    end;
  end;
 
  if FunctionHandle = nil then
  begin
    raise EOleExceptionShai.Create(ERR_MAPPING_COM_API_FUNCTION_NOT_FOUND);
  end;
end;   
 
 
function ShaiFunction(const lpParam: TParamStruct): TResultStruct; 
begin
  InitFunction('ShaiFunction', @APIFunctions._ShaiFunction);
  Result := APIFunctions._SearchPatient(lpParam);
end; 
 
 
function AutreFunction(Truc: PChar): TResultStruct; 
begin
  InitFunction('AutreFunction', @APIFunctions._AutreFunction);
  Result := APIFunctions._AutreFunction(Truc);
end;

[Jognu]

Merci.
Petite question qui n'a rien à voir (mais qui pourrait me simplifier grandement la tâche) : serait-il plus simple d'utiliser cette DLL à partir d'un webservice ?
Il serait effectivement plus pratique pour mon projet d'avoir un webservice plutôt qu'une DLL.
Est-il possible d'utiliser la DLL (ou de l'intégrer à partir des sources) dans un webservice ?

J'ai l'impression que personne n'en parle sur le web, c'est peut-être une idée complètement absurde.

[ShaiLeTroll]

Bien sur, tu peux imaginer tout sorte d'encapsulation, tu peux effectivement au lieu de faire un ActiveX faire un WebService qui se branchera sur IIS, ainsi tu pourras de n'importe quel ordinateur ayant un accès au Serveur Web via HTTP appeler ton WebService, celui-ci appelant en fait la DLL locale ... j'ai déjà vu ce procédé ... maintenant, est-ce que c'est plus simple, ben tout dépend si tu maitrise mieux le déploiement, l'invocation depuis Delphi.Net et l'implémentation en Delphi 7 !!!

Après, tu as commencé en ActiveX, autant le finir (rien que pour la connaissance personnelle acquise des DLL Win32 et des interfaces pour le modèle COM), tu pourras très bien invoqué celui-ci depuis le WebService ...

Regarde par exemple XMLRAD, c'est Serveur ISAPI en Delphi, derrière, il y a tout un ensemble de DLL, ...

Et regardons plus largement, tu développe un WebService, celui-ci utilise plein de DLL sans que tu t'en apercoive, comme les DLL du IXMLDOMDocument qui est utilisé pour générer le XML du SOA ..., donc avoir sa propre DLL interne n'a rien de choquant !