Adresse d'un sous-programme d'évènement

Je suis en train d'ajouter de nouvelles fonctions à ma DLL. Elles seront publiées dans les jours qui viennent. Et, comme pour mes routines de communication entre programmes, j'aurai besoin de pouvoir déclencher une routine évènement dans Panoramic.

Avec mes routines de message, j'ai contourné le problème avec l'utilisation d'un champ edit dont les coordonnées négatives le placent en-dehors de la partie visible de la form, je lui envoie des données par un API et je déclare un on_change dans Panoramic sur ce champ. Ca marche, mais ce n'est pas élégant.

Je sais déclencher une routine évènement dans ma DLL connaissant uniquement son adresse, en fabriquant un TMethodPointer avec l'adresse de ma routine. J'aimerais pouvoir y mettre l'adresse d'une routine Panoramic, afin de pouvoir complètement m'intégrer dans la logique Panoramic.

Pour cela, je suggère une extension de la fonction adr() pour pouvoir lui passer le nom d'un sous-programme en paramètre, ou éventuellement une nouvelle fonction adrsub() pour le même fonctionnement.

Le but est de pouvoir écrire ceci:

Citation :

label ma_routine_evenement
dim res%, dest%
...
dest% = 17 : ' indication pour quelle raison on veut définir l'évènement
res% = dll_call2("SetEventHandler",dest%,adr(ma_routine_evenement))
ou
dest% = 17 : ' indication pour quelle raison on veut définir l'évènement
res% = dll_call2("SetEventHandler",dest%,adrsub(ma_routine_evenement))
...
ma_routine_evenement:
' ici, je traite l'évènement déclenché par ma DLL
...
return

Tu fais des choses très intéressantes. Je vais regarder tout ça.
L'idéal serait de pouvoir créer artificiellement un événement. C'est possible.
A te voire faire tes DLLs, je me demande s'il ne faudrait pas introduire la notion de "plug-in" dans Panoramic. Tu définirais alors tes propres mots-clés (fonction et commandes) avec leurs paramètres et le traitement associé.

Ouaaaaaah ! Cette idée des plug-in me semble très prometteuse !

Regarde mon poste sur mon site:
https://panoramic.1fr1.net/le-site-de-klaus-f11/nouvel-objet-pour-une-form-panoramic-t949.htm
J'y décris l'ajout d'un objet ValueListEditor sur une form Panoramic. J'arrive à créer des routines évènement (on_click par exemple pour cet objet) et à passer l'information à Panormic sous forme d'un évènement (on_change dans ce cas). Bien sûr, il serait beaucoup plus élégant de pouvoir brancher l'évènement directement sur une routine Panoramic, et, comble du raffinement, pouvoir remplacer l'appel un peu lourd de call_dll6("ValueListEditor",...) par quelque chose de plus panoramicien qui serait reconnu par le compilateur...

Cette idée de plug-in me paraît intéressante.
Car je ne cherche guère à utiliser la gestion des dll pour le moment,
du fait qu'on ne peut pas créer des dll en panoramic, ce qui est dommage,
car j'aime bien maîtriser ce que je produit
et non dépendre de morceaux faits on ne sait trop comment.
Si donc on pouvait ajouter des fonctionnalité aux programmes qu'on fait
en gérant nous-mêmes ces fonctionnalités en panoramic,
ce serait génial !
Enfin, c'est mon avis...

Celà serait une bonne chose pour Panoramic si quelqu'un comme Klaus ou d'autres ayant la maitrise de la prog pouvait ajouter des modules.
Je pense que Panoramic s'en trouverait grandit.

L'idée de plugin me parait excellente.
Cela ouvrirai la possibilité de créer des librairies de fonctions avec une syntaxe Panoramic (beaucoup plus parlant que l'utilisation de dll) que l'on pourrait inclure dans nos prog en fct des besoins...

comme vous tous l'idée de plugins me parais excellente mais attention à ne pas tomber dans du thinbasic (isme.
Dedans tout marche par plugins à tel point qu'un seul utilisateur à fait son aide, rien est cohérant, et je les ai quitté pour rejoindre PANORAMIC parce que, bien que moins efficace, PANORAMIC est beaucoup plus intuitif.

Citation :

à tel point qu'un seul utilisateur à fait son aide

Comprends pas ????

Evidemment, tu as raison, Tecking. Si des plug_in voient le jour, cela ne peut être fait qu'avec un encadrement sérieux. Je ne conçois pas non plus lâcher dans la nature de multiples plug-in sans contrôle.

A l'exemple des plug-in pour Mozilla Firefox (et il y en a des tonnes), il faut un accord de Jack pour un nouveau plug-in, afin de préserver l'intégrité de l'ensemble. Cela n'a pas besoin d'être très lourd. Je pense qu'il suffirait de soumettre le plug-in à Jack, par exemple à l'aide d'un message privé en joignant les sources et toute la doc requise, puis attendre la réaction de Jack...

On peut imaginer d'autres moyens. Pour l'instant, les plug-in sont juste une idée prometteuse, mais on ne sait encore rien de précis sur la méthode, le moyen d'interfacer, les normes à respecter etc.