Evènements dans une DLL

Pour pouvoir mieux interfacer une DLL avec un programme Panoramic, j'aimerais pouvoir déclencher une routine évènement Panoramic à partir d'une DLL.

Je sais bien qu'il ne peut s'agir d'un appel direct d'une procédure - l'adresse de la routine n'a pas vraiment de sens dans ce cas. Mais il serait bien de disposer d'un moyen de déclarer un évènement à Panoramic, à l'image de ce que font les commandes ON_... et OFF_..., et de pouvoir placer ensuite un tel évènement dans la pile de Panoramic.

La partie "déclaration" pourrait être faite par une commande Panoramic:
ON_DLL_EVENT N,L
N étant une valeur numérique, et L étant le nom d'une procédure.
Idem pour:
OFF_DLL_EVENT N

Maintenant, il faut un moyen de déclencher un tel évènement à partir de la DLL. Je suggère une variable système DLL_EVENT qui contient l'adresse d'une procédure DELPHI interne à Panoramic, déclarée comme suit:
procedure DLL_EVENT(event_number: integer); stdcall;
On passerait alors cette valeur à la DLL par un paramètre d'une fonction, et ainsi, on pourrait appeler cette procédure à partir de la DLL, avec comme seul paramètre l'identifiant N de l'évènement qu'on veut placer dans la pile.

Avec un tel mécanisme, l'intégration d'une DLL pourrait être beaucoup plus fonctionnelle. Je pense à mon tableur dans lequel je pourrais soumettre des évènements pour sélection d'une ligne ou d'une colonne, pour changement de valeur d'une cellule comme résultat d'un calcul, ou ma DLL de communication entre programmes Panoramic par laquelle je pourrais enfin émettre un évènement "message reçu", etc. Les applications seraient très nombreuses.

Je suis conscient que cela ressemble à une parcelle du problème des "plug-in". Mais sans vouloir aller aussi loin, cette fonctionnalité particulière est peut-être réalisable avec un effort raisonnable...

Bonjour,
J'ignore si ce que je dis est une "connerie". Mais peut-être ai-je une mauvaise idée sur une dll. Pour moi une dll est, pour simplifier un programme, qui est appelé autrement qu'un autre en exec.

Je fais référence par exemple à un programme que j'ai mis en teste en AutoIt pour simuler le double clic. Celui-ci est passé à la trappe, et réellement je m'en "fous" complètement. Mais j'avais récupéré le double-clics en AutoIt, et pour que Panoramic accepte l'évènnement, j'ai imposé le clic que Panoramic comprend par on_clic. J'avais envoyé je crois dans un EDIT une valeur, pour que Panoramic le lise et comprenne que c'était un double clic.

N'ayant que peut de connaissance en Delphi, ne peux-tu pas envoyer dans un EDIT, un code que Panoramic avec ON_CHANGE récupère, ce qui fait un évènnement?

Peut-être procèdes-tu parfois ainsi, et que tu aimerais une souplesse de DLL.

Salutation.

C'est exactement ce que je fais actuellement, pour mes DLL's genre "comminication entre programmes". J'envoie une valeur dans un EDIT de Panoramic, et on a déclaré un ON_CHANGE sur cet évènement en Panoramic. Mais cela impose une contrainte de programmation supplémentaire, avec un EDIT caché pour chaque évènement qu'on veut gérer, avec tout ce que cela implique. Et ce n'est guère lisible dans le source car il n'y a pas de lien évident entre le EDIT et le traitement qui lui est associé, et cela diffère de la façon habituelle de programmer en Panoramic.

C'est pourquoi je suggère des évènements ON_DLL répertoriés par un numéro. Ainsi, chaque DLL peut générer ses propres évènements, et le programme appelant reste maître de recevoir ces évènements ou non, par ON_DLL_EVENT et OFF_DLL_EVENT.

En fait, je me rapproche du mécanisme du TIMER. Je vois quelque chose de très similaire à ON_TIMER er OFF_TIMER.

J'aime mieux cela, je pensais que tu boudais sur mes remarques, et que cela te dérangeait.
Je comprends ce que tu veux dire. Ne sachant faire de dll pour l'instant, je ne peux pas t'appuyer. Seul toi sait la valeur de ta demande, et je suis certain que Jack la comprend.

Je réactive le sujet.
Toi tu demandes la possibilité d'avoir un évènement pour les DLL. Ce que je trouverais bien, c'est de pouvoir récupérer aussi le pendant de execute. On peut envoyer des paramètres, mais pas en recevoir, et c'est bien dommage. Si le programme extérieur ne peut intervenir sur Panoramic, (ce que j'arrive à faire en Auto It, au travers d'un List ou d'un Édit), il ne reste plus que le presse-papiers et les fichiers pour récupérer les paramètres. Et l'expérience m'a montré que le presse papier n'est pas fiable, dans les aller-retour, c'est-à-dire envoi et réception à cadence rapide. Heureusement il y a ta dll pour le presse -papier. À travers le MemoRich que j'ai fait, j'ai trouvé que le temps de transmission entre les deux programmes, est long, alors qu'Auto It, et Panoramic marche ensemble sur des objets communs.

On pourrait même étendre à:
ON_USER_EVENT N,L
OFF_USER_EVENT N

Un utilisateur, dans une DLL ou un exécutable quelconque écrit en PANORAMIC ou dans un autre langage, envoie un événement numéro N.

J'en profite pour signaler qu'il est déjà possible d'activer par un programme externe un événement d'un objet PANORAMIC.

Le principe est le suivant pour le clic sur un bouton de FORM0 à partir d'un programme externe:
- on demande à Windows le handle de la fenêtre PANORAMIC,
- on demande à Windows le handle du bouton qui est sur FORM0,
- on envoie à ce bouton le message équivalent à l'événement "clic"

Si j'ai le temps ce week-end, je vous bricole un exemple très simple en Delphi.

Citation :

ON_USER_EVENT N,L
OFF_USER_EVENT N

c'est exactement ma suggestion, dans une forme un peu plus générale. Si tu fais ça, ce sera parfait.

Ceci dit, il manquera toujours le moyen de déclencher un tel évènement à partir d'une DLL. Je sais bien qu'on peut déclencher un évènement "on_click' ou "on_change", par exemple, en utilisant le mécanisme des messages de Windows. C'est ce que je fais dans certaines de mes DLL's. Mais le gros hic, c'est que ce sont toujours des évènements associés à des objets Panoramic qu'on détourne à cet usage, et qui doivent dont exister. Exemple: dans ma DLL de communication entre programmes, je déclenche un évènement ON_CHANGE sur un EDIT caché lorsqu'un message a été reçu. Opérationnel, mais pas rationnel et pas simple à maîtriser.

Ce qu'il faudrait, ce serait de pouvoir déclencher un ON_USER_EVENT directement dans Panoramic. C'est pourquoi j'ai suggéré une variable système comme ceci:

Citation :

Maintenant, il faut un moyen de déclencher un tel évènement à partir de la DLL. Je suggère une variable système DLL_EVENT qui contient l'adresse d'une procédure DELPHI interne à Panoramic, déclarée comme suit:
procedure DLL_EVENT(event_number: integer); stdcall;
On passerait alors cette valeur à la DLL par un paramètre d'une fonction, et ainsi, on pourrait appeler cette procédure à partir de la DLL, avec comme seul paramètre l'identifiant N de l'évènement qu'on veut placer dans la pile.

On aurait alors l'adresse d'une routine dans Panoramic qui mettrait simplement le USER_EVENT sur la pile des évènements Panoramic, avec le numéro de l'évènement passé sous forme d'un entier de 32 bits comme paramètre unique. Alors oui, on aura de vrais USER_EVENT !

Jack, je me permets de relancer cette suggestion, qui pour moi garde toute son inportance. Pouvoir déclencher un évènement appelant un sous-programme Panoramic, exactement comme un on_click sur un bouton, c'est vraiment ce qu me manque. Pour le moment, il faut que j'impose la création de boutons cachés dans Panoraic, je passe le handle du bouton à la DLL, et je peux ainsi, via un API (SendMessage), déclencher un clic sur ces boutons, afin de lancer les routines évènement. C'est lourd, à la fois dans la DLL et pour l'utilisateur en Panoramic, qui doit créer des boutons invisibles sans trop comprendre ce qui se passe.

L'idée du User_event est très intéressante, pourvu que je puisse disposer d'un mécanisme de le déclencher dans la DLL. As-tu progressé sur ce sujet ?

EDIT

J'avais déjà suggéré cela fin 2010 (ici). Tu as vérrouillé le sujet sans commentaire.

Si cela diminue le nombre d'objets cachés... je suis pour à 1000%...

C'est précisément le but. Les objets cachés ne sont qu'une astuce technique pour simuler ce que mes suggestions pourraient réaliser directement.

Perso, je vote pour !

les objets cachés imposent une grande vigilance sur la numérotation quand on les place
en cours de programme ou en cherchant à améliorer un programme existant.

+1

J'ai réalisé une maquette fonctionnelle pour montrer la faisabilité de cela.

J'ai fait une fonction dans KGF.dll qui est appelée avec un seul paramètre qui représente l'adresse d'une fonction dans le programme principal (une fonction CallBack). Cette fonction CallBack a un seul paramètre: une valeur integer. Et ma fonction DLL appelle cette fonction DLL avec une valeur numérique représentant la seconde de la minute actuelle (0...59).

J'ai fait un programme Delphi indépendant. Dans ce programme, je déclare ma fonction CallBack et qui ne fait qu'une action symbolique: elle place la valeur du paramètre venant de la DLL, dans un mémo, pour contrôle. Ce programme contient aussi un bouton qui déclenche ma fonction DLL.

Voici la fonction dans KGF.dll:

Code:

{  définition du format de la fonction CallBack de Panoramic: un seul paramètre integer}
type
  TFunctionPtr = function (P1: integer) : integer; stdcall;
{ Cette fonction va rappeler la fonction CallBack de Panoramic.
  Cette fonction CallBack est destinée à générer un User Event avec le paramètre passé. }
function FireEvent(const pfunct:TFunctionPtr): integer; stdcall; export;
begin
  pfunct(SecondOfTheMinute(time));    { on passe la valeur de la seconde, à titre d'exemple }
  result := 0;
end;

Ainsi, au niveau de la DLL, il est extrêmement simple de déclencher un User Event.

Dans le programme principal (qui représente le noyau de Panoramic), je déclare la fonction CallBack de la manière suivante:

Code:

{ fonction CallBack pour déclencher un User Event }
function StackEvent(const par: integer):integer; stdcall;
begin
  Form1.Memo1.Lines.Add(IntToStr(par));  { juste pour l'exemple }
  result := 0;
end;

Je présuppose la création d'une nouvelle variable systeme UserEventFunctionAddress contenant l'adresse de la fonction CallBack. On peut imaginer la création de plusieurs de ces variables, donnant chacune l'adresse d'une fonction CallBack différente, chacune avec ses paramètres imposés, en variant le nombre de paramètres, leur type etc. A ce niveau, tout type de données Delphi est utlisable.
Et je simule le dll_call1("FireEvent",UserEventFunctionAddress) pour déclencher l'évènement, de la manière suivante:

Code:

  res := FireEvent(integer(@StackEvent));

Et le tour est joué.

Voici le code complet du programme de démo:

Code:

unit Unit1;

interface

uses
  Windows, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,
  Dialogs, StdCtrls;

function FireEvent(const pfunct:integer): integer; stdcall; external 'KGF.dll' name 'FireEvent';

type
  TForm1 = class(TForm)
    Button1: TButton;
    Memo1: TMemo;
    procedure Button1Click(Sender: TObject);
  private
    { Déclarations privées }
  public
    { Déclarations publiques }
  end;

var
  Form1: TForm1;

implementation

{$R *.dfm}

{ fonction CallBack pour déclencher un User Event }
function StackEvent(const par: integer):integer; stdcall;
begin
  Form1.Memo1.Lines.Add(IntToStr(par));  { juste pour l'exemple }
  result := 0;
end;

procedure TForm1.Button1Click(Sender: TObject);
var
  res: integer;
begin
  res := FireEvent(integer(@StackEvent));
end;

end.

Cela montre qu'il est possible d'avoir un moyen d'appeler une fonction du noyau de Panoramic, avec un ou plusieurs paramètres. Ceci peut servir pour ce problème: les User Event. Mais ce mécanisme pourrait être étendu pour aller vers des plug-in...

EDIT

On pourrait même imaginer une nouvelle fonction Panoramic du genre TObject(N), sur le modèle de la fonction handle(). Cette fonction retournerait l'objet dans le sens Delphi pour l'objet Panoramic numéro n, et on passerait alors cela à une fonction DLL qui pourrait intervenir directement sur l'objet, tant en lecture qu'en mise à jour, par l'utilisation des ses propriétés et méthodes, y compris par l'accès à ces routines évènement.

Penses tu que cela ouvrirait, à condition qu'un delphicien nous explique les choses clairement,
les librairies d'objets delphi tel que les grids colorés ?...

En tout cas, je suis pour tout ce qui te simplifiera la vie pour nous faire des fonctions KGF qui nous
apportent les petits manques de panoramic...

Pas directement. C'est déjà possible via des fonctions DLL. Je le fais pour certains objets Delphi:
- Value List Editor
- Masked Edit
- DateTimePicker
- browser basé sur Internet Explorer
- StringList
- communication entre programmes (IPC)

D'autres sont envisageables. D'accord, pour le moment, c'est laborieux, justement parce que nous n'avons pas le contrôle des évènements, et je dois passer par des objets invisibles dont le déclenche l'évènement on_click ou on_change pour avertir le programme Panoramic. Alors, si Jack fait un pas vers les User Events, cela changera tout, et ces objets deviendront aussi faciles à utiliser que les objets Panoramic, et on pourra rajouter n'importe quel objet dans la liste.

Ok, je suis çà de près moi aussi...

Je complète un peu ma suggestion, pour aller au plus près de la fonctionnalité souhaitée:

- création d'évènements USER_EVENT N avec les commandes ON_USER_EVENT N,L et OFF_USER_EVENT N
- création d'une variable UserEventValue% qui contient une valeur fournie par la DLL au moment du déclenchement de l'évènement
- création d'une variable système de type UserEventFunctionAddress% contenant l'adresse d'une fonction interne au noyau de Panoramic. Cette fonction aurait deux paramètres: le premier serait le numéro du user event à déclencher, et le second une valeur integer fournie par la DLL et qui serait déposée dans la variable interne UserEventValue%
- création d'une fonction TObject(N) qui retournerait un integer contenant la valeur de integer(TObject(objet_N)) en Delphi, avec objet_N étant l'objet Delphi sous-jacent à l'objet Panoramic numéro N. Cette fonction serait l'analogue à la fonction Panoramic HANDLE(N).

On pourrait alors:
- facilement communiquer entre le programme Panoramic et la DLL.
- passer le résultat de TObject(N) à une fonction DLL de même que Handle(N).
- déclencher, les évènements USER_EVENT N via l'adresse contenue dans UserEventFunctionAddress% (qui serait passé en paramètre à une fonction DLL, par exemple juste après le chargement de la DLL).
- déclencher les évènements de l'objet Panoramic directement, en déclenchant directement les évènements Windows de l'objet sous-jacent, en tout cas pour ceux qui ont un équivalent en Panoramic.

Je vais regarder la faisabilité de ce que tu proposes.