@Klaus

@ Klaus,

Toi qui te sert des Luser_event et Wuser_event et qui a compris comment cela fonctionne.
Pourrais tu me dire si ces commandes peuvent servir pour la communication inter-programmes
et nous faire un petit exemple simple.

USER_EVENT_WPARAM et USER_EVENT_LPARAM ne sont pas des commandes, mais des "variables système", au même titre que NUMBER_CLICK. Elles contiennent les valeurs WPARAM et LPARAM d'un message USER_EVENT envoyé par un programme quelconque (le même programme à partir d'une DLL ou d'un autre programme).

On peut évidemmment s'en servir pour une communication inter-programmes. Mais il faut être conscient des contraintes:
1. il faut connaître le handle de la form 0 du programme destinataire auquel on veut envoyer un message
2. ces variables transmettent chacune une valeur entière de 32 bits

Donc, à condition que le "client" connaisse le handle de la form 0 du "serveur" et vice-versa, on peut échanger deux valeurs de 32 bits dont on peut définir librement le sens. Mais, et il y a un MAIS: on ne peut transmettre ni chaines de caractères ni adresses (de type adr(text$) ou adr(tableau%) ). Une adresse n'a de signification qu'à l'intérieur di même "thread", disons à l'intérieur d'un même programme Panoramic pour faire simple. En-dehors, une addresse n'a aucune signification.

Maintenant, rien n'interdit de concevoir un protocole "maison", avec utilisation d'un fichier commun de partage d'information de type Fxxxxxxxx.txt (xxxxxxxx étant une valeur hexa sur 8 caractères), et LPARAM servant de code action. Du genre:
Connexion:
Client signale au serveur (LPARAM=1): "coucou, je suis là, et mon handle de form 0 est dans WPARAM."
Serveur répond si accepté (LPARAM=1): "Ok, noté. Le numéro du fichier de communication est dans Serve
Serveur répond su refusé (LPARAM=2): "Désolé, rejeté. WPARAM = 0."

Demande d'une information:
Client signale au serveur (LPARAM=2): "Je voudrais la liste des clients connectés. Mon numéro de fichier est dans WPARAM."
Serveur écrit la liste des clients connectés dans Fxxxxxxxx.txt, puis répond (LPARAM=3): "Demande satifaite. Liste des clients dans fichier de communication. Nombre de clients dans WPARAM."

Etc. Tu vois que pour chaque interaction, il faut définir un cde action et une réponse appropriée du serveur.

Pour rappel, KGF.dll contient des fonctions de gestion de communication inter-programmes. Voir ici. Ces fonctions résolvent en particulier le problème de la connaissance du handle de la form 0, à l'aide de la notion de "boite à lettre" (une pour le serveur et une pour le client) dont les identifiants sont connus et fixés par le programmeur.

Utiliant KGF.dll, tu peux essayer la fonction suivante:

Code:

res% = dll_call2("FireUserEvent",WParam%,LParam%)

Cette fonction est déjà présente dans KGF.dll, mais non documentée. Elle génère un USER_EVENT dans le programme qui appelle cette fonction. Tu peux ainsi essayer la commnication avec un seul et même programme puisque la fonction détermine automatiquement le handle de sa form 0. Si ce type de traitement de convient, je pourrai faire une fonction

Code:

res% = dll_call3("FireUserEvent",handle%,WParam%,LParam%)

avec laquelle tu pourrais joindre un autre programme.

@ Klaus,

Voilà ce que je voudrais pouvoir faire.
je voudrais rendre mes outils indépendant du programme principal.
Prenons l' exemple de la palette de choix de couleur.
Cet outils permet le choix d une couleur qui peut être traduite en un nombre comme pour les couleurs kgf.
Si je transforme cet outils en exécutable, lorsque celui ci est lancé par le programme principale, je peux lui transmettre un paramètre qui peut être le Handle du form 0 du programme principal.
Mais quand je valide la couleur dans l' outils il faudrait que je puisse avertir le programme principal de cet validation et qu' il récupère le résultat.

Je pensais que ces variables pouvaient servir  a ça...
 

Mais je cherche un moyen de faire cela en Panoramix
Et sans multiplier les fichiers externes...

Pour ce problème particulier, il n'y a pas besoin d'un fichier externe, en effet. La réponse à tansmettre est la couleur qui est une valeur 32 bits, et donc parfaitement adaptée pour être transmise pa WPARAM ou LPARAM, laissant l'autre variable pour éventuellement transmettre autre chose.

Dans ce contexte, ton outil de sélection de couleur serait considéré comme "le serveur", et le programme Panoramic "le client". Si tu veux transmettre le handle de la form 0 au serveur par un paramètre au lancement par EXECUTE, cela suppose qu'un seul programmme Panoramic "client" à la fois se servira du "serveur", non ? Tu n'envisages pas que plusieurs programmes Panoramic, actifs simultanément, puissent vouloir se servir du sélecteur de couleurs ?

Supposons le cas 1 "client" avec 1 "serveur". Dans ce contexte, le lancement du "serveur" par EXECUTE effectué par le "client" correspont au "login" du "client" vers le "serveur". L'identité du "client" (le handle de sa form 0) est mémorisée dans le "serveur".

Première question: est-ce que le sélecteur de couleurs doit être visible et actif en permanence ou seulement lorsque le "client" attend un choix de couleurs ? C'est une décision cruciale, car avec un programme séparé comme "serveur", il n'y a aucun moyen de contrôler à quel moment ce "serveur" va envoyer son message avec la couleur. L'évènement ON_USER_EVENT peut être déclenché à n'importe quel moment. Est-ce que c'est ce que tu cherches ?

Si tel est le cas, lorsque l'évènement arrive, il faut que le "client" mémorise cette couleur comme étant la nouvelle couleur choisie, pour pourvoir l'utiliser par la suite, au moment opportun. Et cela devient impossible si le client a besoin de plusieurs couleurs, comme dans un éditeur de code par exemple, qui a besoin d'une couleur pour le fond, d'une autre pour le texte, etc.

Si le client ne veut activer le serveur que lorsqu'un choix de couleur est ç effectuer dans un but précis (pour la couleur de fond, pour la couleur du texte, ...), alors il faut procéder autrement. Lors du lancement du "serveur", ce dernier mémorise toujours l'identité de son "client", démarre et construit tout ce qu'il faut, mais reste caché (HIDE de la form 0 du "serveur"). Lorsque le serveur est prêt à fonctionner, il envoie un message au client, avec WPARAM=0 (signifiant "je suis prêt") et LPARAM étant le handle de la form 0 du serveur. Le client, de son côté, après avoir lancé le "serveur" par EXECUTE, doit attendre ce message, mémoriser LPARAM (l'identité su "serveur"), puis continuer son traitement normal.

Lorsque le "client" veut obtenir une couleur (clic sur un bouton, par exemple), le "client" doit envoyer un message au "serveur" avec WPARAM=1 (signifiant "je veux une couleur") et LPARAM étant le handle de la form 0. Par sécurité, le "serveur" vérifie qu'il s'agit bien de la même valeur que celle mémorisée à son démarrage (l'identité du "client"). En suite, il fait un SHOW de sa form 0 et c'est tout. Lorsque l'utilisateur aura choisi et validé une couleur, le serveur envoie un message au "client" avec WParam=1 (signifiant "voilà la couleur démndée") et LPARAM=valeur de la couleur. Ensuite, le serveur se cache par un HIDE de sa form 0.

Le client, de son côté, recevant le message avec la couleur demandée, peut l'utiliser à sa guise.

Comme tu vois, il y a deux moments stratégiques où le "client" n'a absolument pas la maîtrise des évènements: au lancement du serveur et lors de la demande d'une couleur. Dans les deux cas, on lance une action (démarrage du "serveur" par EXECUTE ou demande d'une couleur), mais on ne sait pas du tout si et quand le "serveur" répondra. Il faudra donc attendre, sans bloquer la machine, et réagir en cas de dépassement d'un time-out dans le cas cu lancement initial. Par contre, lors de la demande d'une couleur, aucun time-out ne peut être appliqué, car il s'agit d'une réponse de l'utilisateur qui, après avoir cliqué sur le bouton de sélection de couleur, a pu décider d'aller prendre un café...  Tout ceci rappelle étrangement les problèmes de synchronisation que rencontre Jack avec le lancement d'un programme à partir de l'éditeur.

Ma conclusion est simple. Tu as un bel outil, sobre et performant. Mais en voulant faire une telle architecture, tu vas le transformer en usine à gaz qui restera forcément instable, pour les mêmes raisons que celles que rencontre Jack. C'est faisable mais techniquement compliqué. Si tu choisis cette voie, je pourrai t'assister, développer les systèmes d'appel et d'attente. Mais je me permets de te déconseiller cette approche.

EDIT

Désolé d'avoir été si long, mais le sujet méritait une explication précise.

Bonjour à tous,

J'ai un peu de mal avec ce sujet qui est trop compliqué pour moi, mais je crois en avoir saisi les grandes lignes.

Si j'ai bien compris, Yannick, a besoin de communiquer entre 2 programmes Panoramic.
Si le but est de faire un choix de couleurs, pour utilisation dans le programme principal, en utilisant "Palette.exe", alors j'ai une solution assez simple.

1) l'appel de "Palette.exe" se fait avec EXECUTE_WAIT à partir du programme principale, ce qui fait que celui-ci se trouve bloqué (neutralisé)  tant que "Palette.exe" n'est pas fermé.

2) "Palette.exe" écris les données (Ici, les couleurs) choisies par l'utilisateur dans un fichier "ResultatSelectPalette.txt" et à sa fermeture rend le focus au programme principal.

3) dans le programme principale, et juste après la ligne EXECUT_WAIT "Palette.exe", on récupère les données du fichier "ResultatSelectPalette.txt" pour les utilisées.


Voilà, en gros comment je procéderais....

A+

@ Klaus,

Ne soit pas désolé de la longueur de ton explication. Le sujet est complexe pour un programmeur de mon niveau, il vaut mieux prendre quelques lignes de plus et que les choses soient claires.
Je vais même garder cette page en mémoire dans les favoris au cas où la mienne me ferait défaut .
Je te remercie de tes explications.
L' aide de Panoramic est trop courte pour ce genre de truc, cela mériterait un exemple concret d' utilisation,
deux programmes courts communiquant entre eux.

@ Jean Claude,

C' est une solution mais c' est ce que je voulais éviter, la création d' un fichier temporaire
dont on ne maitrise pas forcement l' emplacement.

En tout cas merci à tous les deux.

Comment ça, tu ne maîtrises pas l'emplacement d'un fichier

Il te suffit d'utiliser dir_change.
Pourquoi ce fichier doit-il être temporaire
Perso, je pense qu'à chaque fois que "Palette.exe" est appelé, il faut écraser l'ancien fichier en utilisant FILE_OPEN_WRITE. Ou le supprimer (FILE_DELETE) une fois que l'on a extrait les données.

A+

Et tu le crées où ton fichier ?
Pas dans le dossier racine, si l' utilisateur installe dans Program files, tu ne pourras pas y écrire.
Dans C:\, qui te dis que C:\ est le nom de volume de l' utilisateur ?...
Le système de fichiers est il celui de Mac, Windows, Android ?...

Autant de questions que de réponses si ce n' est plus.

Ben, je crée le fichier dans le répertoire (ou sous-répertoire) du programme principale.

Effectivement, ma solution ne marche que dans le répertoire où se trouve le programme principal.

Citation :

si l' utilisateur installe dans Program files, tu ne pourras pas y écrire

Heu..., tu es certain de ça ??? (de toute manière, ce n'est pas l'utilisateur qui écris, c'est le programme principal qui fait le boulot )

A+

Essais, tu verras...

Pour pouvoir y écrire il va falloir changer les autorisations dans les propriétés du dossier.
Et je ne pense même pas que l' on puisse y accéder.

Promis, je ferais l'essai, mais tu as l'air d'avoir expérimenté, du coup je crains le résultat de mon essai.

Mais pas maintenant, car j'ai piscine...

A+

A moins que Jack dans sa bonté nous offre une fonction permettant la récupération des différents dossiers système comme le fait KGF avec GetWindowsFoldersPath

Cette fonction retourne pas moins de 60 dossiers différents ! Et c'est ici

Je crains qu' avec tout ce qu' on lui demande, Dieu soit débordé pour quelques temps.

Wouais, il va nous maudire !

Bonjour à tous,

@Yannick,

Comme j'avais un doute, je viens de faire l'essai d'écrire dans un fichier en partant du Prog1 qui EXECUTE_WAIT "Prog2 ". Prog2 écrit "bonjour" dans le fichier fich.txt. A la fermeture de prog2, Prog1 charge fich.txt dans un list pour vérifier, puis DELETE "Prog2".

Les 2 Prog(s) sont en exe et tous les deux dans le même répertoire.

j'ai fait 3 essais:
1) le répertoire (dossier) est sur le bureau, je lance "Prog1.exe". Tout marche bien.
2) je déplace le répertoire à la racine => ça marche aussi.
3) je déplace le répertoire dans "Program files (x86)" => ça marche aussi. Seule différence, Windows m'informe que je dois disposer des droits....,

Voici les 2 programmes à enregistrer dans le même dossier et à transformer en exécutable.

Prog1

Code:

' prog1
dir_change dir_current$
caption 0,"Prog1.exe"
list 1

EXECUTE_WAIT "Prog2.exe"

File_load 1,"fich.txt"

file_delete "fich.txt"

END

Prog2

Code:

' Prog2.exe
dir_change dir_current$
caption 0,"Prog2.exe"
left 0,300 :font_bold 0:font_size 0,20
print "écriture du fichier"

file_open_write 1,"fich.txt"
file_writeln 1,"bonjour"
file_close 1

end

Hé, Yannick...

J'attends ta réaction !

Désolé Jean Claude,

J' aurai voulu te répondre que j' étais dans mes amours mais
c' était mes emmerdes et leur paperasse et du coup mes amis attendent des réponses...


Je suis heureux que chez toi cela fonctionne bien mais je doute que tout le monde puisse le faire.
J' ai eu le souci en installant SimpleEditor par le setup d' inno, je ne pouvais pas enregistrer mes paramètres
Ce qui fait que maintenant il l' installe sur C:\

En fait il faudrait que ce soit testé par des Panoramiciens avec des OS différents.

A votre bon cœurs messieurs et mes-dames !

A+

@Jean Claude
Sous XP, ça marche

@Yannick
L'idée de base est là, ça devrait suffire pour faire communiquer 2 forms ensemble : dans cet exemple, l'évènement est envoyé sur le form de l'exécutable en cours, à lui même donc. Mais tu peux l'envoyer vers un autre form en spécifiant son nom dans la variable 'form_name$'.
Je n'ai jamais fait ça, je ne peux pas certifier que ça va marcher, c'est territoire inconnu là! Mais bon, il n'y a pas de raison que ça ne marche pas...

Code:

   label Traite_User_Event

    ' nouvelle commande utilisateur
    On_User_Event Traite_User_Event
    '
    ' syntaxe : SEND_EVENT(form_name$,value1%,value2%) ; nom du form cible à adapter
    SEND_EVENT("panoramic V 0.9.28i7",12,34)

    
    END
    Traite_User_Event:
     Off_User_Event
     '
     '
       select USER_EVENT_LPARAM
       case 12
               message "USER_EVENT_LPARAM = "+str$(USER_EVENT_LPARAM)+chr$(13)+chr$(10)+"USER_EVENT_WPARAM = "+str$(USER_EVENT_WPARAM)
       end_select
     '
     '
     On_User_Event Traite_User_Event
    return



' SUB
    sub SEND_EVENT(form_name$,value1%,value2%)
     if variable("event_index%")=0
        ' cré la commande qui permet de déclencher un évènement
        dim event_index%,user32%
        if variable("user32%")=0 then dim user32%
        event_index%=4024 : user32%=2   :' event_index% doit toujours avoir la valeur 4024
        LIBRARY user32%,"user32.dll"
        command "call_user_event","SendMessageA",user32%,"IIII","stdcall"
     end_if
     '
    ' déclenche l'évènement(Attention, c'est toujours et uniquement le form 0 de l'executable en cours qui active la commande 'on_user_event'!)
    call_user_event handle_form(form_name$),event_index%,value1%,value2%    
    end_sub

Là il va falloir que je m'accroche, c'est du lourd

@Silverman, merci pour ta réponse et ton essai. Il me manque W7, mais j'ai ce qu'il faut à la maison.

A+

@ Silverman,

Merci pour ton code, je vais tester tout cà dans ce week-end.