Discussion :

[ShaiLeTroll]

J'ai un problème, je l'ai déjà mentionné dans ce sujet dans le forum C# mais pas de réponse probante...

Donc, j'ai réalisé un objet COM pour un partenaire qui utilise le Framework .NET,

Il a pu recenser mon objet dans son namespace, il peut l'instancier et appeler une méthode sans problème ...

mais la plupart des méthodes prennent un paramètre, et l'une des plus simples échoue

Code :

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

1
2
3
4
type
  IShaiTruc = interface(IUnknown)
    function SearchMachin(const ChaineID: WideString): ISearchResult; stdcall;
end;

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
function TShaiTrucImpl.SearchMachin(const ChaineID: WideString): ISearchResult;
var
  ObjRes: TSearchResultImpl;
  S: string;
begin
  ObjRes := TSearchResultImpl.Create();
 
  S := ChaineID; // Boom ICI, la chaine ChaineID ne contient pas du tout ce qu'il faut, même pas le moindre "1" (Code 31 00)
  ObjRes.FData := ShaiTruc_API_Header.SearchMachin(PAnsiChar(S)); // Ici, j'appelle la DLL Win32, si je ne met pas la conversion de ChaineID, ça continue son chemin ...
 
  Result := ObjRes; 
end;

et bien, impossible de lire ChaineID, je n'ai pas de violation d'accès mais la mémoire ne contient pas du tout ce qu'il devrait ...
J'ai donc testé d'aller plus loin en ignorant le paramètre, et j'ai une violation d'accès sur l'affectation du Result, et oui IsBadWritePtr me dit que Result n'est pas inscriptible ... génant ...

Alors qui a déjà fait un COM Delphi Win32 pour un environnement .NET, et quelles sont les astuces côté Delphi ou côté VB\C# qui permettent que cela fonctionne ...

Pour le moment, je suis sur un autre projet, mais si je n'ai aucune solution lors de la reprise de l'objet COM, eh bien faudra faire à la place un WebService, ... et refaire encore, refaire ça me gave ... sachant qu'à la base, l'objet COM n'est qu'une encapsulation d'une DLL Win32 qui soit disant n'est pas intégrable en VB.NET (pourtant j'ai vu qu'il existait DllImport ... bon ...)

[Franck SORIANO]

Ben il y a une chose qui me perturbe :

function SearchMachin(const ChaineID: WideString): ISearchResult; stdcall;

Sur un objet COM, une méthode doit obligatoirement avoir un Hresult comme type de retour.
Pour renvoyer une valeur de retour, il faut obligatoirement la passer dans un paramètre de sortie.

Delphi est capable d'automatiser ce mécanisme par l"intermédiaire de la convention d'appel safecall. C'est sans doute ce que tu as l'habitude d'utiliser.

Dans ton cas de figure, je suis même étonné que ton objet COM fonctionne si tu l'appelle depuis Delphi. Je pense que le compilo doit se perdre dans le passage des paramètres au moment de l'appel, d'où l'erreur qui te dit que Result n'est pas affectable.

De plus, j'ai un doute que .NET soit capable d'utiliser des objets COM qui ne sont pas "compatibles OLE Automation". D'une façon général, pour faire de l'interop il faut que tout soit OLE Automation, c'est le seul moyen d'être sûr que le client et le serveur connaitront tous les types de données utilisés.

Bref, tu devrais essayer de redéfinir ton objet COM en le déclarant compatible OLE Automation. Ca t'obligera à déclarer tes interfaces Dual. Elles utiliseront alors toutes la convention d'appel safecall.

Je pense qu'ensuite, tout devrait marcher comme sur des roulettes.

sachant qu'à la base, l'objet COM n'est qu'une encapsulation d'une DLL Win32 qui soit disant n'est pas intégrable en VB.NET (pourtant j'ai vu qu'il existait DllImport ... bon ...)

Pourquoi n'est-elle pas intégrable ? qu'est-ce qu'elle a de si particulier ? Est-ce que tu peux donner le prototype des fonctions que tu veux appeler ?

bien faudra faire à la place un WebService

Attention, la dernière fois que j'ai essayé je me suis rendu compte que Delphi et VS avaient du mal à se comprendre. Les enveloppes SOAP générées par Delphi sont erronées (du moins dans la version avec laquelle j'avais fait le test (D6 ou D2005 je ne me souvient plus). Delphi déclare un namespace au début de l'enveloppe, puis ne l'utilise que pour la moitié du message. Pour VS, une fois le NS déclaré, les éléments qui s'y rapportent doivent avoir le prefix. Du coup, le message SOAP est ignoré et le serveur ne répond pas aux requêtes Delphi.

[ShaiLeTroll]

Sur un objet COM, une méthode doit obligatoirement avoir un Hresult comme type de retour.
Pour renvoyer une valeur de retour, il faut obligatoirement la passer dans un paramètre de sortie.

Ce n'est pas moi qui est défini le code de l'interface mais l'éditeur de TLB, si on ne doit pas changer le result, il mettrait une erreur je pense, non ?
Mon interface est Dual (IDispatch), le result HResult est implicite ... et quand j'ai voulu mettre mon interface en sortie, il rallait car ce n'est pas un pointeur ...
Mes accesseurs renvoie un Hresult car c'est obligatoire ... en fait si tu es en IDispatch, le HResult semble ne plus être obligatoire pour les fonctions car selon si je change de classe de base, il change le prototype ...
Ah ma classe d'implémentation de base est TAutoObject...
en fait, j'ai repris un de mes vieux ActiveX, j'ai pompé ce que j'y avais mis, ... mais encore une fois c'était Delphi to Delphi ...

et puis j'ai le message avec la paramètre de sortie interface :

Code :

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

Le paramètre de sortie nécessite un type pointeur.

Delphi est capable d'automatiser ce mécanisme par l"intermédiaire de la convention d'appel safecall. C'est sans doute ce que tu as l'habitude d'utiliser.

Euh, en fait, les interfaces, je n'en fait pas souvent ... tient, tient

Code :

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

    procedure CloseSearch(const SearchResult: ISearchResult); safecall;

une voie à explorer ...

Dans ton cas de figure, je suis même étonné que ton objet COM fonctionne si tu l'appelle depuis Delphi. Je pense que le compilo doit se perdre dans le passage des paramètres au moment de l'appel, d'où l'erreur qui te dit que Result n'est pas affectable.

Il fonctionne a merveille en Delphi, j'ai même filé un programme de test, et cela fonctionne sur le poste du programmeur qui doit utiliser mon objet ...

De plus, j'ai un doute que .NET soit capable d'utiliser des objets COM qui ne sont pas "compatibles OLE Automation". D'une façon général, pour faire de l'interop il faut que tout soit OLE Automation, c'est le seul moyen d'être sûr que le client et le serveur connaitront tous les types de données utilisés.

Euh, elle le sont déjà dans la TLB, basé sur IDispatch et StdOle2.tlb

Pourquoi n'est-elle pas intégrable ? qu'est-ce qu'elle a de si particulier ? Est-ce que tu peux donner le prototype des fonctions que tu veux appeler ?.

C'est ce qu'il m'a dit, mais au téléphone, je viens d'y penser, il a cru que la DLL Win32 utilisait des interfaces, alors que j'ai des trucs genre, je lui ai même donné en speudo C et en pascal

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
  struct TSearchResult
  {
    int ErrorCode;
    unsigned int Count;
    unsigned int ID;
  };
 
  typedef short WORD;
  struct _SYSTEMTIME // Voir le type de l'API Windows
  {
    WORD wYear; 
    WORD wMonth; 
    WORD wDayOfWeek; 
    WORD wDay; 
    WORD wHour; 
    WORD wMinute; 
    WORD wSecond; 
    WORD wMilliseconds; 
  } SYSTEMTIME; 
 
  typedef _SYSTEMTIME  TSystemTime; 
  typedef _SYSTEMTIME  *PSystemTime;
 
  struct TPatient
  {
    LPTSTR lpIdentifiant: ;
    LPTSTR lpNom;
    LPTSTR lpPrenom;
    PSystemTime lpDDN;
    LPTSTR lpNSS;
    LPTSTR lpLocalite;
    LPTSTR lpCodePostal;
  };

Code :

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

1
2
3
TSearchResult SearchPatient(LPTSTR lpNumeroReference); // Pseudo C
 
function SearchPatient(lpNumeroReference: PChar): TSearchResult; stdcall;

Rien de méchant ...

Attention, la dernière fois que j'ai essayé je me suis rendu compte que Delphi et VS avaient du mal à se comprendre. Les enveloppes SOAP générées par Delphi sont erronées (du moins dans la version avec laquelle j'avais fait le test (D6 ou D2005 je ne me souvient plus). Delphi déclare un namespace au début de l'enveloppe, puis ne l'utilise que pour la moitié du message. Pour VS, une fois le NS déclaré, les éléments qui s'y rapportent doivent avoir le prefix. Du coup, le message SOAP est ignoré et le serveur ne répond pas aux requêtes Delphi.

Aucun problème, on ferait de toute façon, nous ferons du WebSerivce en Php4\NuSOAP avec un bon vieux EasyPhp 1.8 (c'est ce qui est installé chez nos clients, on installe EasyPhp incluant MySQL car nos applis tourne sur cette DB que l'on utilise via TMyDAC de CoreLab en D7)
Mais entre Delphi et Php, on a jamais eu de problème ... donc, on espère qu'il n'y en aura pas entre Php et VS ...

[Franck SORIANO]

Ce n'est pas moi qui est défini le code de l'interface mais l'éditeur de TLB, si on ne doit pas changer le result, il mettrait une erreur je pense, non ?

L'éditeur de TLB est loin d'être un modèle de qualité. Tu peux changer le type de retour uniquement si tu fais une interface de type VTable pure (pas de dual, pas de IDispatch).
Dans une interface dual, pour définir une valeur de retour, il faut créer un paramètre de sortie avec les flags "Out" et "RetVal". Pour pouvoir les définir, il faut effectivement que le type du paramètre soit un pointeur (l'interface va être renvoyée par référence). Et pour définir ce pointeur, il faut écrire :

Code :

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

ISearchResult *

comme type de paramètre. Et oui, on est dans Delphi mais l'éditeur de TLB fait du C. (quand je dis que ce n'est pas un modèle de qualité...).

Mes accesseurs renvoie un Hresult car c'est obligatoire ... en fait si tu es en IDispatch, le HResult semble ne plus être obligatoire pour les fonctions car selon si je change de classe de base, il change le prototype ...

Le problème c'est que tu es en dual (et il faut le rester). La dispinterface ne retourne pas de HResult (le HResult c'est la sauce interne de l'interface IDispatch), par contre l'interface classique elle a besoin du Hresult.

Redéfinit le type de retour de la méthode à Hresult (il ne faut jamais changer le HResult de toute façon dans un objet COM). Puis ajoute ta valeur de retour comme un paramètre de sortie.
Cette fois l'éditeur de TLB doit te générer l'interface en utilisant safecall et non pas stdcall.

Sur du dual, tu ne devrais pas avoir de stdcall.

Code :
TSearchResult SearchPatient(LPTSTR lpNumeroReference); // Pseudo C

function SearchPatient(lpNumeroReference: PChar): TSearchResult; stdcall;

Rien de méchant ...

Renvoyer une structure comme valeur de sortie, ce n'est pas très courant pour une DLL. Je ne sais pas si cette valeur de retour est faisable avec un DllImport.

[ShaiLeTroll]

Code :

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

ISearchResult *

.

mais c'est ce que j'ai mis, de toute façon, c'est la seule chose que la TLB propose ... mais pourquoi ! j'ai le message d'erreur

Sur du dual, tu ne devrais pas avoir de stdcall.

je devrais avoir SafeCall, c'est ça, faut donc que je la refasse ... bon, je vais refaire juste un objet avec deux interface bidon pour un test ... pas tout me retaper merde ...

Renvoyer une structure comme valeur de sortie, ce n'est pas très courant pour une DLL. Je ne sais pas si cette valeur de retour est faisable avec un DllImport.

ah, c'est vrai, ça se change facilement les exports win32, hop couper coller, ... c'est pas la TLB en dur dur ...


A Lundi !

[ShaiLeTroll]

Je reviens, pour vous informer que l'on peut mettre

Code :

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

ISearchResult **

cette possibilité n'est pas proposer comme type dans la liste de l'editeur de TLB mais semble acceptée quand même, je vais revoir mon implémentation, et je reviens conclure, si cela fonctionne ou pas !
cela pourrait servir à d'autre ...

la suite est ICI

EDIT, bon, en fait, en mettant le ** au lieu du *, je peux cocher dans l'éditeur de TLB "Out" et "RetVal", ce qui donne à mes fonctions la même tête qu'en modifiant le résultat de la fonction mais conserve le SafeCall qui est utilisé par le VBScript ou par .Net ...

[Franck SORIANO]

Je reviens, pour vous informer que l'on peut mettre

ISearchResult **

cette possibilité n'est pas proposer comme type dans la liste de l'editeur de TLB mais semble acceptée quand même, je vais revoir mon implémentation, et je reviens conclure, si cela fonctionne ou pas !
cela pourrait servir à d'autre ...

Effectivement, j'avais oublié ça (quand j'écris un objet COM, en général je me débrouille pour ne pas avoir à retourner d'interface).

En fait, une interface c'est un pointeur qui se déclare ISearchResult * dans l'éditeur. Pour définir la valeur en type de retour, il faut définir un pointeur sur le pointeur, donc ISearchResult **.

[ShaiLeTroll]

en général je me débrouille pour ne pas avoir à retourner d'interface

Tu ne sembles pas le seul, personne ne m'a répondu vraiement à mes trois sujets, à par toi, qui finalement était le plus proche de la solution, et donc, j'ai effectivement l'impression que l'echange d'interface via function n'est pas courant (où il y aussi le fait que je parle de Delphi dans un forum C#, et que du coup, beaucoup détourne les yeux ... , ou tout simplement, dans ce langage, c'est tellement plus implicite, qu'ils ne connaissent absolument pas les aspects sous-jacents de celui-ci, en tout cas, mon interlocuteur qui doit intégré mon objet, n'a pas fait preuve de grande connaissance, faut dire qu'au début, je lui dit que je lui proposais un DLL Win2 ou un ActiveX, il me répond qu'il préfère une DLL Win32, et il me sort qu'il ne peut pas l'inclure à son référentiel de classe, ben euh, logique ... j'ai du refaire par dessus la DLL une sur-couche COM, je me suis bien amusé pour la gestion mémoire des PChar, cela m'a fait de l'exercice , ... et idem, il a fallu que je découvre le VBScript pour faire mes tests, un script qui mérite une certaine attention finalement ...)


Sinon, Il est très con, l'Editeur de TLB, le Message d'Erreur n'est pas explicite, on a un pointeur, et il nous réclame un pointeur, je trouve qu'il pourrait même le proposer automatiquement, en fait si cela n'avait été de la syntaxe C, j'aurais surement eu l'idée bien avant, c'est en étudiant les accesseurs de mes autres classes que j'ai vu le ** ... et ce fut donc l'illumination

[Franck SORIANO]

il y aussi le fait que je parle de Delphi dans un forum C#, et que du coup, beaucoup détourne les yeux ...

Surtout qu'en fait, c'est un problème purement Delphi...

tout simplement, dans ce langage, c'est tellement plus implicite, qu'ils ne connaissent absolument pas les aspects sous-jacents de celui-ci

Et bien en fait, on ne peut pas faire d'objets COM en dotNET. Donc ceux qui connaissent uniquement dotNET ne savent absoluement pas de quoi tu parles ni comment ça fonctionne. Le framework est tellement riche que tu n'as pas besoin d'appeler d'objets COM. Et lorsque tu veux prendre une appli en Automation, tu références la TLB dans les dépendences du projet, comme une assembly ordinaire, et tu manipule l'appli comme une classe ordinaire...

En dotNET, tout fonctionne par réflexion. Les interfaces existent et constituent un certain confort, mais une interface en dotNET ce n'est pas très différent d'une classe abstraite. Il n'y a pas de comptage de référence (garbage collector oblige), pas de QueryInterface (un simple cast fait l'affaire), pas de GUID pour identifier l'interface...
D'ailleurs, tu peux caster l'interface pour retrouver la classe physique qui l'implémente...

Par contre, tu peux faire une classe dotNET qui sera utilisée via interop par un objet COM, ou une application Win32.

il a fallu que je découvre le VBScript pour faire mes tests

Tu peux également faire les tests avec Delphi, en travaillant en late-binding au lieu de faire de l'early. Ca fonctionnera à l'identique de ce que fait VBScript.

Sinon, Il est très con, l'Editeur de TLB, le Message d'Erreur n'est pas explicite, on a un pointeur, et il nous réclame un pointeur, je trouve qu'il pourrait même le proposer automatiquement, en fait si cela n'avait été de la syntaxe C, j'aurais surement eu l'idée bien avant, c'est en étudiant les accesseurs de mes autres classes que j'ai vu le ** ... et ce fut donc l'illumination

Si ça peu te consoler, c'est le meilleur outil du genre que j'ai pu trouvé.
Essaie de faire ton objet COM en C++. Il n'y a aucun editeur, tu dois déclarer l'interface dans un fichier source MIDL et la compiler avec une ligne de commande...