Comment importer une DLL dans du code???

Bonjour à tous...

Je travaille sous Delphi 2006 (version pro) et je réalise un programme en VCL .NET... Jusque la tout va bien :) mais dans ce programme je souhaite faire appel à des DLL qui se trouve sur un répertoire du disque mais je ne peut pas tous les charger par avance avec DLLimport (DLL Win32) car c'est l'utilisateur du programme par la Form qui m'indique les DLL qui veut utiliser....

Est-ce possible???? (de charger une DLL dans du code et non dans la Déclaration..)

merci d'avance... :wink:

PS: je suis un novice en programmation :oops:

Borland a ajouté un système très pratique permettant de lier les DLL à l'exécution sous .NET, il y a d'ailleurs un brevet là dessus, mais cette technique n'est pas très connue et tu ne trouveras pas grand chose sur le web..
Extrait d'une de mes conférences données aux DevTracks Borland l'année dernière qui donne un exemple de déclaration :

Virtual Library Interfaces (VLI)
*Simplifie l’importation de DLL Win32 sous .Net
*Ajoute la flexibilité indispensable pour le « Late Binding » absent de P/Invoke
*Déclaration originale dans la DLL Win32 (exemple)
function ConvertCtoF(CentValue: Integer): Integer; stdcall; function
ConvertFtoC(FahrValue: Integer): Integer; stdcall;
* Déclaration typique P/Invoke sous .Net utilisant les attributs personnalisés (pour appel à la dll win32) :

function ConvertCtoF; external;
[DllImport('Win32DLL.dll', CharSet = CharSet.Auto, EntryPoint = 'ConvertCtoF')]

function ConvertFtoC; external;
[DllImport('Win32DLL.dll', CharSet = CharSet.Auto, EntryPoint = 'ConvertFtoC')]

Problème P/Invoke :
peu pratique, verbeux,
le nom de la DLL ou son chemin ne peut être résolu au runtime
si la DLL n’est pas trouvée = erreur d’exécution.
Exemple :
Déclaration d’une interface contenant le nom des procédures à importer:

type IWin32DLLInt = interface
function ConvertCtoF(CentValue: Integer): Integer;
function ConvertFtoC(FahrValue: Integer): Integer; end;

Ajouter l’espace de nom Borland.Vcl.Win32

Appel à travers l’interface :

var MyDLL: String;
MyWin32DLL: IWin32DLLInt;
begin
MyDLL := ExtractFilePath(Application.ExeName) +
'\mylib\Win32DLL.dll' ;
if not Supports(MyDLL, IWin32DLLInt, MyWin32DLL) then
MessageBox.Show(self, ‘Ne peut charger Win32DLL.dll') else
NewInt := MyWin32DLL.ConvertCtoF(100);

et je defini quand le prototype des fonction de ma DLL????

Citation:

---

Envoyé par Jayceblaster

et je defini quand le prototype des fonction de ma DLL????

---

c'est à dire ?
Si tu parles des prototypes de fonctions importées, avec VLI elles sont créées en tant qu'interfaces dans le code de l'application utilisatrice. Il faut donc connaître ce prototypage à la compilation, comme avec du P/Invoke classique. La seule différence tient dans le fait que VLI permet d'indiquer le chemin et le nom au runtime et qu'il permet aussi de tester le support des prototypes, le tout sans créer de chargement systématique des DLL et sans planter l'appli, ce qui est le cas avec P/Invoke.

Ben supposons que l'utilisateur du programme souhaite importer une dll permettant de commander une alim par une liaison GPIB. Il va falloir importer, par exemple, les fonction "ReglageTension", dont le prototype sera le suivant:

Code:

---

1 2	erreur := ReglageTension (Valeur Tension a generer: float);

---

Il faut bien a un moment que je déclare ce type comme je peut le faire avec le DLL Import...
Non???

ah oui je viens de comprendre (rooooooo je suis long :lol: )

Il faut absolument que je déclare le prototype de mes fonctions dans l'interface...

Y a pas d'autre moyens....

Car moi mon appli devra etre capable d'appeler jusque qu'a 50 DLL alors en terme de fonction c assé lourd...

Citation:

---

Envoyé par Jayceblaster

ah oui je viens de comprendre (rooooooo je suis long :lol: )
Il faut absolument que je déclare le prototype de mes fonctions dans l'interface...

---

voilààààà :-)

Citation:

---

Y a pas d'autre moyens....

---

Les DLL win32 n'ont pas de mécanisme de "découverte" à la base. Pas possible de lister les exports et leurs paramètres de façon claire, il faut déclarer les prototypes et il faut en avoir la liste.
Les DLL .net peuvent être inspectées par réflexion, mais pas les win32.

Citation:

---

Car moi mon appli devra etre capable d'appeler jusque qu'a 50 DLL alors en terme de fonction c assé lourd...

---

Oui, cela me semble lourd, et puis 50 DLL win32, ça veut dire que presque tout le code de l'appli est non managé... à quoi bon faire l'appli en .NET alors ? au tant la réaliser en c++ ou en Delphi win32 non ?

non le .NEt est indispensable car dans ce lot de DLL il n'y a pas que du Win 32 il y a aussi des assemblages dotNet (pour piloter des instruments de mesure)...
C'est quoi la méthode d'importation dans le code des assemblage .NET dont tu parles (ca pourrai peut etre me servir)?

Est si c'est possible en .NET, je pourrais peut etre envisager "d'encapsuler toutes les DLL win32 dans des assemblage .NET (j'ai deja fais ca...)

Merci pour ton coup de main Merlin...

Ps:: j'espere ne pas paraitre trop C... avec mes post mais je galere un peut car de formation électronique j'ai pas trop l'habitude avec le soft (je fais tous ca dans le cadre d'un stage... :wink: )

Citation:

---

Envoyé par Jayceblaster

non le .NEt est indispensable car dans ce lot de DLL il n'y a pas que du Win 32 il y a aussi des assemblages dotNet (pour piloter des instruments de mesure)...

---

oui mais il est possible d'utiliser des assemblages .NET dans une appli Win32 via COM, donc si 90% est non managé, l'appli pour l'être aussi et pour les 10% de .NET cela passerait par COM sur les assemblages .NET.
Mais bon, si tu veux/dois le faire en partant sur une application .NET pourquoi pas, de toute façon dans un cas comme dans l'autre il faut jongler puisqu'il y a des DLL des deux types.

Citation:

---

C'est quoi la méthode d'importation dans le code des assemblage .NET dont tu parles (ca pourrai peut etre me servir)?

---

.NET permet de charger un assemblage en mémoire et ensuite par les mécanismes de réflexion tu peux partir à la découverte des classes qu'il contient, de leurs méthodes, etc.
Si tu as Delphi 2005 ou 2006 il y a un exemple d'appli "reflector", sinon sur le web tu trouveras certainement le source de ce type de programme qui permettent d'inspecter ce qu'il y a dans un assemblage.
Mais bon, dans ton cas tu n'as pas forcément besoin d'autant de souplesse, tu connais les DLL à utiliser et ce à quoi elles servent. Donc le mieux c'est d'importer les fonctions comme on en a parlé ici. Avec ou sans VLI d'ailleurs, VLI apportera juste un peu de souplesse.

Citation:

---

Est si c'est possible en .NET, je pourrais peut etre envisager "d'encapsuler toutes les DLL win32 dans des assemblage .NET (j'ai deja fais ca...)

---

je ne pense pas que dans ton cas tu y gagneras beaucoup.

Citation:

---

Merci pour ton coup de main Merlin...
Ps:: j'espere ne pas paraitre trop C... avec mes post mais je galere un peut car de formation électronique j'ai pas trop l'habitude avec le soft (je fais tous ca dans le cadre d'un stage... :wink: )

---

L'informatique est tellement riche et complexe que même pour un pro c'est facile de passer pour un C.. comme tu dis.. C'est un métier qui force à l'humilité et on est tous débutant dans plein de domaines même après des années d'expérience :-)

Alors je viens de regarder l'exemple fourni avec DELPHI et je dois dire que j'ai trouvé ca plutot costaux....
Je suis donc allé sur internet et j'ai trouvé (sur ce site) une introduction sur la réflexion en C# et la encore je me suis cassé les dents :( .

Pour l'instant le seul truc qui est claire dans ma tête c'est la manière d'importer une DLL de manière logique et physique (pour dire a quel point je suis largué)...

N'y a-t-il pas une propriété dans Assembly me permettant de récupérer d'un coup le nom et le prototype des fonction dans la DLL spécifié?

Car la je galere entre les GetType et GetMembers....

:wink:

Citation:

---

Envoyé par Jayceblaster

N'y a-t-il pas une propriété dans Assembly me permettant de récupérer d'un coup le nom et le prototype des fonction dans la DLL spécifié?
Car la je galere entre les GetType et GetMembers....

---

Hélas, c'est la façon unique de procéder..
Mais c'est pas si compliqué, c'est un peu comme les RTTI de Delphi mais en plus générique.
Tu as un assemblage, il expose des classes, elles exposent des méthodes et des attributs etc..

Le meilleur moyen c'est que tu partes sur un petit bout de code avec une classe bidon et que tu essayes de lister son contenu par réflexion.
Part d'un truc minimaliste et super simple et tu verras que c'est finalement pas la mer à boire :-)

En fait je suis parti d'un truc que je connais bien. En effet j'ai l'habitude de travailler avec des instrument de mesure et j'ai donc repris une DLL NI (National Instrument) permettant de piloter des cartes d'acquisition. Il s'agit donc d'une DLL .NET, dont je connais le prototype de toutes les fonctions sur le bout des ongles pour l'avoir utiliser à plusieur reprise....
J'ai donc écris une petite appli (en m'inspirant de l'exemple fourni avec Delphi 2006).
Voici mon code (il vaut ce qu'il vaut surtout qu'il marche pas... :( )

Code:

---

1 2 3 4 5 6 7 8 9 10 11

Var maDLL : Assembly; type1: System.Type; Propriete: ProprietyInfo; begin //je charge ma DLL maDLL:= Assembly.loadFrom('C:\NIDAQmx.dll'); //je charge (d'apres moi :? ) la propriété que je souhaite utiliser) Propriete:= maDLL.Gettype.GetProperty ('ReaderSingleSampleSingleLine');

---

Après ca je pense pouvoir attaquer ma fonction de la maniere suivante:

Code:

---

1 2	ValeurLue := Propriete('Channel0');

---

Mais à l'exécution un message d'erreur apparait pour m'indiquer qu'il n'a pas trouvé la propriété.....

Mon code à l'aire légé en fait mais j'ai essayé de me contenter du minimum.... Peut etre trop :lol: ...

pour obtenir la valeur, ça serait plutôt qqchose dans le genre
Propriete.GetValue(...,...); en mettant ce que GetValue réclame comme paramètres.

Ben en fait le problème se situe deja des la deuxieme ligne de code...

Code:

---

1 2 3

Propriete:= maDLL.Gettype.GetProperty ('ReaderSingleSampleSingleLine');

---

Propriété est nul comme si il ne trouvait pas la propriété dans ma DLL alors qu'elle existe (je l'ai ouvert avec reflector)....

Mais ce que tu réclames (le ReaderSingle...) est ce une propriété ou une méthode ? si c'est une méthode getProperty ne la verra pas.

le mieux pour ton essai serait que tu utilises getProperties qui renvoie un tableau, et tu fais un petit foreach pour afficher tous les noms.. Comme ça tu pourras vérifier si celui que tu recherches est bien dans la liste...

En fait j'ai pas mal avancé (enfin facon de parler :) )

J'ai créé une ptite DLL qui me permet de faire l'addition de 2 entiers et qui me retourne un entier qui correspond au résultat de l'opération...
Voici le source de cette fonction:

Code:

---

1 2 3 4 5 6 7

function Add (int a, int b): int; {   int resultat = 0;   resultat = a + b;   return resultat; }

---

Maintenant mon objectif est de récupérer par réflection le nom de ma fonction, les noms et type des paramètres attendus en entrée et renvoyé.

j'ai donc écrit un ptit programme en C# (desolé c pas du Pascal mais je maitrise mieux le C#). Voici le source:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19

Assembly SampleAssembly = Assembly.LoadFrom ("c:\\essaiDLL_AddDotNet.dll"); foreach(Type Ttype in SampleAssembly.GetTypes()) {   listBox1.Items.Add(Ttype.Name); //affichage de tout les types     foreach(MethodInfo Mmethode in Ttype.GetMethods())   { listBox2.Items.Add(Mmethode.Name); foreach(ParameterInfo Pparametre in   Mmethode.GetParameters())   {   listBox3.Items.Add(Pparametre.Name); }   } }

---

Ce code me permet d'afficher dans 3 listBox tout les types, méthode et paramètre de ma DLL. Je retrouve donc mon Add et mon "a" et "b" mais je n'arrive pas a récupérer leur type (int).

et je n'arrive pas non plus a dire de récupérer que les parametre de la méthode Add (je les récupére tous)....

Qu'en penses tu???? :wink:

Quand tu obtiens ton ParameterInfo, il suffit au lieu d'accéder à Name d'accéder à la propriété ParameterType et de faire un ToString() dessus pour l'afficher, ça te donnera le nom du type du paramètre.

Pour le langage cela n'a aucune importe, ce sont majoritairement des appels au framework et en Delphi.NET ou C# ça revient au même. Sous Delphi tu utiliserais For ... in au lieu de foreach c'est à peu près toute la différence :-)

Encore merci pour ton aide Merlin, car sans ton aide je serais perdu dans cette jungle qu'est la réflection :lol:

Mais encore une fois je galere un max...
je t'explique...
J'ai donc créé une appli avec 3 listBox qui me récupérent

- les Types de mon assmblage
- les méthodes de mon assemblage
- les paramètres de toutes mes méthodes

Et je dois dire que le résultat est étonnant pour une simple DLL d'addition. En effet je récupére une multitude d'info. Par exemple (ceci n'est qu'un ptite extraction de ce que j'obtiens)

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

Les Types: .... $map$ Math StrUtils SysUtils essaiDLL_AddDotNet // ce que je veux $map& .... etc.   Les méthodes: ... ToString Add // ce qui m'intéresse getType Equals .... etc.   Les paramettres: ... Obj a // ce qui m'intéresse b // ce qui m'intéresse FileName Guide ...etc.

---

Pourquoi pour une misérable DLL comme la mienne je récupére autant de chose???? (je rappelle que la il ne s'agit que d'une extraction de ce que j'obtiens (1/20eme de ce que je récupére en tout))

Et en fait comment dois je faire pour récupérer que le type qui m'intéresse à savoir "essaiDLL_AddDotNet"???
En sachant que je ne peux pas écrire:

Code:

---

1 2	Type := monAssemblage.getType('essaiDLL_AddDotNet');

---

...Puisque je ne suis pas sensé connaitre l'existence de ce type.

Et enfin lorsque je récupére les paramètres de la fonction Add, j'arrive à récupérer les parametres d'entrée mais pas le paramètre de retour qui correspond au résultat de l'opération???

Merci d'avance... :wink:

L'assemblage qui te sert de test est visiblement fait en delphi.net, et tu découvres les coulisses.. les contraintes de compatibilité ascendante font que les assemblages delphi.net contiennent beaucoup de choses qui brouillent un peu les pistes. Tu ferais le même exemple avec un assemblage en c# tu verrais que les données de la reflexion seraient moins nombreuses.
Mais bon, cela ne change pas trop ton pb, sauf que là, tu as beaucoup d'infos qui ne te servent à rien, donc le tri est plus difficile.

Pour obtenir les infos de la méthode qui t'intéresse, le mieux c'est de balayer la liste comme tu le fais pour remplir la listbox, mais au lieu de remplir une listbox tu t'arrêtes quand le nom est celui que tu cherches (avec string.compare par ex). Tu devrais pouvoir y accéder directement mais bon, essayons d'avancer :-)
Tu peux faire pareil pour les méthodes. Et donc récupérer les infos de la méthode Add de cette façon.

Mais le problème c'est que je ne suis pas sensé connaitre le contenu de mon assemblage donc impossible de faire "string. compare".

Dans mon application finale je devrai etre capable d'explorer n'importe quelle DLL DotNet (je dois réaliser une sorte de logiciel Reflector mais plus poussé car il devra etre capable d'instancier n'importe quel classe d'un assemblage DotNet)

En fait j'ai l'impression que lorsque je récupére les Types de mon assemblage il faut que j'indique la "méthode" de recherche via un BindingFlags mais j'en suis vraiment pas sur...

Faire marcher "n'importe quelle DLL" me semble impossible par nature. Si ton application n'a pas connaissance à l'avance des signatures des méthodes des classes, je vois mal comment elle pourrait les appeler en leur passant par exemple les "bons" paramètres.
C'est pas jouable conceptuellement.
Lorsqu'une appli charge des dll dynamiquement, elle connait toujours ce qu'il a dedans. La gestion des plugins est par exemple souvent basée là desus, chaque dll peut avoir des fonctions très différentes mais pour être reconnue comme plugin utilisable elle doit, par force, exporter un certain nombre de choses fixées à l'avance qui forme le protocole, le contrat entre l'appli et ses plugins.
Donc soit j'ai pas tout compris (ce qui est possible), soit ce que tu veux faire est de toute façon impossible.

Ben je pense que ca doit etre possible puisque le logiciel réflector le permet ( logiciel permettant d'explorer n'importe quelle DLL.)

En fait je suis obliger de procéder ainsi car je dois réaliser un séquenceur de test générique qui va permettre de réaliser n'importe quel banc de test rapidement (pour le test de cartes électroniques)... l'utilisateur du séquenceur pourra par la suite lancer n'importe quel test en appelant les DLL qui vont bien en fonction des tests qu'il veut réalisé (voila en quelque mot :wink: ).

Mais je voit peut etre une autre solution, j'ai cru comprendre que l'on pouvait via la réflection récupérer le contenu de toute une fonction (son code) et puisque c'est moi par la suite qui vait créer les DLL utilisables par le séquenceur je n'ai qu'a créer une fonction commune à chaque DLL qui renfermerai le prototype de toutes les fonction qu'elle contienne....

En sais tu d'avantage sur cette possibilité (récupération du code d'une fonction )?

merci d'avance :wink:

Oh le cas intéressant! Un cas de projet de développement sans conception.

Vous confondez 2 usages distincts de la reflection:
1) Charger l'assembly dans le code pour instancier l'un de ces types.
2) Coder un explorateur de types.

D'abord, vous avez découvert le projet winform Delphi.Net Reflect et à tord ou à raison vous souhaitez intégrer ce code dans votre projet.
(Ca rassure et donne le sentiment d'avoir bien progresser, on a du code!):)
Ensuite, vous cherchez à construire votre projet autour de ce code.

Comprenez qu'un explorateur de type est à l'usage d'un utilisateur qui souhaite par exemple s'informer de la signature d'une méthode,
ce qui ne correspond pas au besoin de votre projet, et que d'autre part, comme le souligne Merlin,
il est vain de vouloir opérer des traitements sur des données si l'on pose la condition de vouloir ignorer la nature même de ces traitements. 8O

Vous écrivez:

Citation:

---

Mais le problème c'est que je ne suis pas sensé connaitre le contenu de mon assemblage donc impossible de faire "string. compare".

---

Ce n'est pas le problème.
Le probleme est de charger des assembly et instancier des types.

A mon avis, si vous avez par exemple une dll pour chaque type de RAM(edo, sdram) avec un jeu de fonctions en commun , implémentez la pattern Adaptateur,
créez une interface de base (facade) qu'implémentent les types contenus dans vos DLL et laissez jouer le polymorphisme dans le code. :D

Je ne peux qu'agréer les sages conseils de Fabrice.

Un programme comme Reflector permet d'inspecter un code, pas d'utiliser ce code. Cela fait une nuance importante. Le résultat de reflector sont à usage de l'oeil et de la sagacité humaine, pour documentation.
On peut se baser sur la reflexion pour "découvrir" les classes exportées et pourquoi pas pour les instancier.
Mais dans l'exemple pris, la fonction "add", comment l'application peut-elle l'appeler correctement si elle n'a pas été conçue _avant_ pour lui passer les _bons_ paramètres ?
C'est impossible par nature.

Il n'y a que deux possibilités raisonnables : soit, comme le conseil Fabrice, utiliser la design pattern decorateur pour habiller chaque dll avec une interface commune, soit créer un outil totalement générique offrant du scripting pour piloter n'importe quelle dll.

Cette dernière option n'est pas si compliquée à mettre en oeuvre en C# puisqu'on peut compiler du code C# à l'exécution en invoquant les services du compilateur.
On peut donc supposer un outil avec compilateur c# et debugger permettant d'écrire du code pour piloter les dll.
Mais cela est malgré tout un projet ambitieux, même s'il est réalisable.

Bienvenu Fabrice dans cette discussion :wink:

Vous me faites tres peur avec vos deux derniers post, je joue mon diplome la ... :?

Non mais y a un truc que je saisi pas trop...

Vous etes bien d'accord que la réflection permet:

1--> de connaitre le contenu d'un assemblage

2--> d'instancier lors de l'exécution une méthode (Invoke)

Non???

Alors pourquoi serai-je réveur de penser qu'il m'est alors possible de récupérer le prototype d'une fonction contenu dans un assemblage et de l'instancier...?

Au fait Fabrice j'ai l'impression que tu m'as donné un bout de solution mais je dois dire que je n'ai pas tres bien saisi.... Désolé de me répéter mais je suis loin d'etre une star en développement, je débute :oops:

Peux tu détailler ou m'indiquer un lien qui m'éclaircirait le sujet? :wink:

Puisque vous souhaitez effectuer un appel de methode via la reflexion, mettons cela en oeuvre.

Commençons par créer un projet class library en C#.

Code:

---

1 2 3 4 5 6 7 8 9 10 11

namespace Library1 {   using System;   public class Library1   {   public int Add(int a, int b){   return a + b;   } } }

---

Maintenant on crée un petit projet console C# pour tester notre dll.
Remarquez que nous allons cristalliser l'appel à la méthode de classe de l'assembly dans une méthode de même nom.
Ainsi le code appelant n'a pas à savoir comment s'effectue réellement l'appel.

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23

namespace Project1 {  using System;  using System.Reflection;   public class Test {     static object Add(int a, int b) {   Assembly assembly = Assembly.LoadFrom("Library1.dll");   Type type = assembly.GetType("Library1.Library1");   object target = assembly.CreateInstance("Library1.Library1");   object[] args = {a,b}; object result = type.InvokeMember("Add", BindingFlags.InvokeMethod, null, target, args); return result; }   public static void Main(string[] args){   Console.WriteLine("Resultat: " + Test.Add(4,8));   Console.ReadLine();   } } }

---

Pour en revenir à la design pattern Adapteur, l'idée est que les classes de votre projet n'appellent pas directement les méthodes
des types instanciés de l'assembly dont les signatures diffèrent.
Elles communiqueront avec une interface.;)

Une classe Adaptateur implémentera cette interface et effectuera les appels aux méthodes de l'assembly.

Ainsi votre code n'aura pas connaissance du mécanisme de la reflexion, c'est à la charge de l'adaptateur.8-)
Votre code est client de l'interface, l'assembly est l'adapté et la classe Adaptateur se situe entre les deux.

Ce mécanisme est l'une des voies possibles pour effectuer des appels génériques.
Une autre méthode proposée par Merlin est de mettre en place une pseudo grammaire et un interpréteur en se basant sur la possibilitée
de compilation à la volée et d'exécution de code.

Merci beaucoup Fabrice pour cette exemple qui m'a beaucoup aidé....

Je l'ai donc adapté a mon problème et en jonglant avec des fichiers textes qui renfermeront quelques info sur mes Dll je devrai m'en sortir...

J'ai essayé de passé ton exemple (un peu modifié) en Delphi.net et j'obtiens une erreur.

Voici mon code:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16

procedure TForm1.AdditionClick(Sender: TObject); var monObjet, result : System.Object; arguments : array [1..2] of System.Object; SampleAssembly : Assembly; tType: System.Type; begin SampleAssembly := Assembly.LoadFrom('c:\dllAddition.dll'); tType := SampleAssembly.GetType('dllAddition.dllAddition1'); monObjet := SampleAssembly.CreateInstance('dllAddition.dllAddition1'); arguments[1] := a1.Text; arguments[2] := a2.Text; result := Ttype.InvokeMember('Add', BindingFlags.InvokeMethod, nil, monObjet, arguments); resultAdd.Text := string(result); end;

---

A l'exécution j'ai une erreur à la ligne du "InvokeMember" me disant que le membre n'a pas été trouvé.
Alors que ce meme code fonction en C# (en adaptant la syntaxe bien sur :D ).

Bon j'ai trouvé l'erreur c'est au niveau du type Object...

Il faut écrire:

Code:

---

1 2 3

arguments[1] := System.Object (StrToInt(a1.Text)); arguments[2] := System.Object (StrToInt(a2.Text));

---

En C# le problème ne se pose pas car la convertion doit être implicite.

Ceci dit je trouve cette écriture un peu lourde (j'ai pas trouvé mieux :? )

;)

Ah les transtypages...
Pour ma part, je n'ai pas vraiment mieux à proposer.
On peut écrire également:

Code:

---

1 2	argument[1] := System.Object(System.Convert.ToInt(a1.Text));

---

Mais en ce qui me concerne je suis assez réticent à utiliser la VCL.NET.
Son avenir et son évolution reste incertain.
Si dans le futur un développeur décide de passer le code en C#, cela passera nécessairement par la réécriture de toutes les interfaces.
De plus, ces dernières qui s'appuyent sur la VCL.NET ne sont pas partageables entre développeurs dotnet.