String et Serveur COM

Version imprimable

22/09/2006, 14h37
WebPac

String et Serveur COM

Salut tout le monde,

je suis en train de développer des objets automation. Je suis ce tutoriel : ftp://ftp-developpez.com/delphi/cours/com/Automat.pdf qui est très bien.

Je dois avoir été mal habitué avec Delphi, passant du C++ à Delphi, quel ne fut pas mon bonheur de découvrir que l'utilisation des string est extrèmement simple. Malheureusement, ce type n'existe pas dans les autres langages et son usage dans des objets COM pose problème de la même façon qu'il pose problème dans les dll.

Il existe 3 solutions :
* Mettre ShareMem en premier uses du projet de la bibliothèque ActiveX ET dans les projets utilisant les objets automations.
* Remplacer tous les string par des PChar.
* Remplacer tous les string par des ShortString.

Mais je ne sais pas si la librairie ShareMem existe dans tous les langages et je me vois mal obliger les utilisateurs de mes objets COM à devoir inclure en premier cette librairie.
L'utilisation des PChar est plus fastidieuse à devoir gérer la taille du PChar à la main. Dans le document qui explique l'utilisation des PChar dans les dll : http://alphomega.developpez.com/DllString/
il est dit qu'il faut à chaque fois passer la taille max du PChar en paramètre.
L'utilisation des ShortString est limitant à 255 caractères.
Est-ce que les WideString peuvent être utilisés pour remplacer les ShortString ?

Mon soucis est que je devrais modifier toutes les sources, il y a plusieurs dizaines de milliers de ligne s'il faut, je voudrais trouver la meilleure solution avant de commencer ce gros travail.

Pour info, je ne connais pas à priori les langages qui utiliseront ces objets COM, sûrement au minimum, Delphi, C++, C#, VB .Net.

Merci pour vos conseils.
25/09/2006, 10h04
cmen76

Mes serveurs COM / DCOM ont des propriétés WideString et cela fonctionne sans problème.
25/09/2006, 10h08
WebPac

Merci pour cette info, ça me rassure d'apprendre cette nouvelle.

Les clients COM / DCOM sont uniquement en Delphi ou dans d'autres langages ?
25/09/2006, 10h33
cmen76

Ils ont été écrits en Delphi, mais on a réussi à les utiliser aussi bien depuis d'autres programmes en Delphi que de procédures stockées SQL Server...
En même temps, c'est aussi un peu le but, que le serveur COM puisse être appelé de partout quel que soit le langage.
25/09/2006, 10h40
WebPac

Citation:

Envoyé par cmen76

Ils ont été écrits en Delphi, mais on a réussi à les utiliser aussi bien depuis d'autres programmes en Delphi que de procédures stockées SQL Server...
En même temps, c'est aussi un peu le but, que le serveur COM puisse être appelé de partout quel que soit le langage.

Tout à fait, mais en lisant de la doc sur les objets COM, ça expliquait que le but des dll était le même mais qu'au final trop de dll ne sont pas portables sur d'autres langages que celui avec lequel elle a été créée, voire même pas portable sur d'autres IDEs.
C'était donc le but de ma question d'être sûr que les WideString étaient portables pour les autres langages, les string ne l'étant pas.

Autre question (désolé de t'embêter mais tu m'aides bcp), est ce que tu as dû changer tous les string internes en WideString ou est-ce juste tes objets COM qui n'utilisent que des WideString ?
25/09/2006, 10h55
cmen76

Je suis d'accord avec toi pour les DLL, mais le souci principal était justement que leur définition est généralement orientée dans le sens du langage utilisé.
L'intérêt de l'interface COM/DCOM est justement de proposer une plateforme standard indépendante des langages. C'est pourquoi on n'y retrouve pas nos types Delphi, mais des types Windows.
Pour répondre à ta question, dans l'implémentation j'utilise les types Delphi (string et autres), mais dans la déclaration de l'interface COM je n'utilise que des types Windows.
25/09/2006, 11h20
WebPac

Citation:

Envoyé par cmen76

Je suis d'accord avec toi pour les DLL, mais le souci principal était justement que leur définition est généralement orientée dans le sens du langage utilisé.
L'intérêt de l'interface COM/DCOM est justement de proposer une plateforme standard indépendante des langages. C'est pourquoi on n'y retrouve pas nos types Delphi, mais des types Windows.
Pour répondre à ta question, dans l'implémentation j'utilise les types Delphi (string et autres), mais dans la déclaration de l'interface COM je n'utilise que des types Windows.

C'est parfait, c'est exactement ce que je désirais faire aussi. :D