Pour communiquer avec les fonctions DLL, les possibilités sont très restreintes. Plusieurs limitations sont assez gênantes:
1. le nombre de paramètres est limité à 6
2. tous les paramètres doivent être passés "par valeur" - pas de passage "par référence"
2. les paramètres doivent obligatoirement être de type INTEGER
3. in n'est pas possible de passer un tableau (de INTEGER bien sûr)
4. impossibilité de déclencher un évènement Panoramic
J'aimerais suggérer les améliorations et extensions suivantes:
a. lever la limitation à 6 paramètres.
Il serait bien de pouvoir passer le nombre de paramètres qu'on veut. Et, certes, si la fonction appelée réclame un nombre de paramètres différents, il pourrait y avoir une erreur Panoramic "Syntax error", ou à la limite un crash, car l'erreur du programmeur est évidente.
b. il serait très utile de pouvoir passer un tableau, via une variante de la fonction ADR qui pourrait être ADR_ARRAY(MonTableau%).
Le résultat de cette fonction serait l'adresse des données de l'élément MonTableau%(0) ou MonTableau%(0,0). Ceci bien sûr dans l'hypothèse que les données sont stockées dans une zone mémoire contigüe. Et, comme ADR, la fonction ADR_ARRAY devrait marcher également sur des tableaux de flottants et de chaînes de caractères. Dans tous les cas, elle devrait retourner l'adresse des données de la première cellule. Il est de la responsabilité du programmeur de la DLL de faire le bon usage de cette valeur, en tenant compte de l'espace occupé par chaque type d'information (entier, flottant ou chaîne de caractères), exactement comme c'est actuellement le cas pour ADR. Dans le cas d'un tableau de chaînes de caractères, le contenu des 32 (ou 64) bits pointés par ADR est un pointeur vers le contenu de la première cellule qui est lui-même un pointeur vers le texte de la chaîne de caractères (un PString en Delphi). Car je suppose qu'un tableau de chaînes de caractères en Panoramic est mémorisé sous forme d'un tableau INTEGER dont chaque cellule contient un PString pointant les la chaîne de caractères proprement-dite ?
c. pouvoir déclencher un évènement Panoramic.
Actuellement, je le fais en utilisant on objet EDIT caché par HIDE, ayant un évènement ON_CHANGE. Et dans la DLL, j'utilise l'API SendMessage avec le code WM_SETTEXT pour déposer un texte dans cet objet (identifié par son handle). L'évènement se déclenche, et je peux le traiter en Panoramic. Or, ceci est lourd et nécessite un objet Panoramic "abusé" de cette façon. Je suggère un évènement spécifique DLL_EVENT qui serait géré par les commandes:
ON_DLL_EVENT label
OFF_DLL_EVENT
et on déclencherait cet évènement par un SendMessage avec le code message de type "user_defined" PANORAMIC_DLL_EVENT qui pourrait avoir la valeur WM_USER+x (WM_USER = 0400 hexa, et x étant choisi par Jack). Et ce message serait adressé à la form 0 dans tous les cas, ce qui déclencherait l'évènement ON_DLL_EVENT qui appellerait alors le label en question. Et les valeurs LPARAM et HPARAM du message seraient mises à disposition du programme Panoramic dans des variables système DLL_LPARAM et DLL_HPARAM.
On peut certes imaginer un interfaçage plus complexe, en particulier avec le passage de paramètres "par référence (pouvoir retourner une valeur par un paramètre), avec la déclaration de prototypes des fonctions préalable au premier appel, etc. Mais je pense que cela sort du concept de Panoramic. Alors, j'ai essayé de définir un ensemble cohérent mais restant dans la ligne de ce qui existe.
Evidemment, ce sont juste des suggestions. La seule "nouveauté est la fonction ADR_ARRAY qui serait vraiment très utile.
Accueil 
Calendrier
