CALL FORM, DIALOG et DIALOG(...,*)

Je voulais comprendre comment CALL FORM fonctionne lorsqu’il y a plusieurs fenêtres d’ouvertes dans même process avec DIALOG(…;*).

D’abord, merci à Gabriel Inzirillo pour cette https://forums.4d.com/Post/FR/27461408/0/0/#27607115base exemple>, elle a constitué un parfait point de départ pour fabriquer mon test ci-dessous :
https://forums.4d.com/4DBB_Main/x_User/4467/files/28425906.zip

Une fois lancé :
• exécuter la méthode “Launch_membre_list”, elle ouvre la fenêtre de la liste, “L”, dans un process “P”
• ouvrir une (ou plus) fenêtre DIALOG(…;) par double clic dans la liste, appelons-les “S” comme saisie
à ce stade, on a donc dans P une “main window” ouverte par DIALOG et des “secondary windows” ouvertes par DIALOG(…;
)
• clic dans L sur le bouton “Lancer appelant”
• ouvre un nouveau process “A” comme “appelant”, qui liste les fenêtres de P
• double cliquer sur un des numéros de fenêtre dans A effectue un CALL FORM (laFenêtreDePCiblée;laMethodeCallForm;…)

Constat : la seule fenêtre qui exécute laMethodeCallForm est toujours la “main window” L, jamais une des S.
Ce que j’interprète ainsi :

  • je passe à CALL FORM un numéro de fenêtre
  • 4D l’utilise pour identifier le process de cette fenêtre, puis la “main window” de ce process
  • enfin cette dernière exécute la méthode

La doc de https://doc.4d.com/4Dv17R3/4D/17-R3/CALL-FORM.301-3906606.fe.htmlCALL FORM> : « La commande APPELER FORMULAIRE exécute la méthode projet dont le nom est passé dans méthode avec un ou plusieurs param(s) optionnel(s) dans le contexte d’un formulaire affiché dans la fenêtre, indépendamment du process auquel appartient la fenêtre. »
Les deux mentions en rouge ne me convainquent pas trop, par rapport à ce que je vois. Des remarques ?

As-tu essayer de mettre a fenetre concernée au premier plan avant de faire ton call form?

As-tu essayé (tout court) ? :lol:

oui oui alors pas compris ton problème

Dans appelerForm_mng,

change la partie

<code 4D>
If ($arr_p->>0)
$win_l:=$arr_p->{$arr_p->}
$message_t:="CALL FORM émanant de "+String(Current process)
CALL FORM($win_l;“alerter”;$message_t)
End if
</code 4D>

par

<code 4D>
		If ($arr_p->>0)
				$win_l:=$arr_p->{$arr_p->}
				HIDE WINDOW($win_l)
				SHOW WINDOW($win_l)
				$message_t:="CALL FORM émanant de "+String(Current process)
				CALL FORM($win_l;"alerter";$message_t)
			End if 

</code 4D>

et dis moi si c’est bien ce que tu recherches à obtenir

Je n’ai pas été clair, on reprend.

Je ne cherche pas à obtenir quoi que ce soit, j’observe (pour comprendre).

On me dit d’une part qu’un seul process peut ouvrir plusieurs fenêtre, une ouverte avec DIALOG que j’appelle main window, et d’autres avec DIALOG(…;*) que j’appelle secondary windows. Dans l’exemple de Gabriel, main window = la liste, secondary window = une saisie.

On me dit d’autre part que CALL FORM reçoit une référence de fenêtre en 1er paramètre, et que “Tout comme dans la communication interprocess basée sur les workers, une boîte aux lettres (BAL) est associée à chaque fenêtre”.

Donc je regarde cette histoire de BAL pour chaque fenêtre. Je constate que la fenêtre qui exécute le CALL FORM (refFenetre;nomMethode) est toujours la main window, jamais une des secondary windows, bien que je mentionne explicitement une secondary window dans CALL FORM.

Tout ça me fait penser que, au choix,
• s’il y a bel et bien une BAL par fenêtre, de toutes façons seule la main window relève ces BAL
• la doc est trompeuse, il n’y a pas une BAL par fenêtre mais par process

PS :
en fait c’est aussi cette astérisque de DIALOG(…;*) qui me travaille. Jusqu’à la v16r5, la doc était assez vague (pour ne pas dire elliptique) et mes essais complètement foireux. Maintenant qu’on a DIALOG(“leForm”;objetParametre) et Form, ça me semble plus intéressant. Comme toute fenêtre, je me demande comment c’est qu’on lui cause - depuis un autre process, j’entend. L’outil pour ça est CALL FORM qui marche avec le principe de la queue de messages, ou BAL. D’où l’envie de comprendre cette histoire de “une BAL par fenêtre”.

: Arnaud DE MONTARD

Je constate que la fenêtre qui exécute le CALL FORM
(refFenetre;nomMethode) est toujours la main window, jamais une des
secondary windows, bien que je mentionne explicitement une secondary
window dans CALL FORM.

sauf que tu fais : message_t:="CALL FORM émanant de "+String(Current process) comme message de ton appel à call form et que ta méthode “alerter” appel toujours le même dialogue. Si tu regardes bien, ton message est bien envoyé à la bonne fenêtre, mais tu n’en fais rien au niveau de ta fenêtre (suis clair??).

Bin ça me semble clair, pourtant : je dis à une fenêtre ref1 “exécute cette méthode” et c’est une fenêtre ref2 qui exécute la méthode en question.

Ouf, j’ai compris grâce à Patrick et ses patientes explications en privé. Comme je testais avec une méthode qui exécute DIALOG, 4D ne peut le faire que dans la main window. Si le message est quelque chose de plus anodin, comme colorer un rectangle, ça se passe bien dans la fenêtre ciblée.
https://forums.4d.com/4DBB_Main/x_User/4467/files/28431444.zip

Donc attention à ce qu’on demande de faire à une fenêtre cible : si elle est une secondary window et qu’on lui demande d’ouvrir un dialogue, elle refile la patate chaude à la main window.

Ouf et merci !

bonjour

Voila une petite babase pour mettre tout le monde d’accord; enfin j’espère :slight_smile:
J’ai utilisé cette mini base lors d’une formation. Elle fait à la fois appel à des CALL WORKER et des CALL FORM


Je ne sais pas si ça va éclairer les esprits, mais :

CALL WORKER(“CallFormDemo”;“ManageDials”
pourrait etre traduit en (in french in the text)

Demande au worker “CallFormDemo” d’exécuter la “ManageDials”
(et si le worker “CallFormDemo” n’existe pas encore, STP 4D, crée le !)

quant à :

CALL FORM($win;“UpdateDial”;…)
pourait etre dit de la façon suivante:
STP 4D, exécute la méthode “UpdateDial” dans le contexte du dialogue actuellement ouvert dans la fenêtre $win.

(à apparenter avec la commande “execute métho in subform”)

Voir la méthode “WorkerSteps”, c’est elle qu’il faut lancer…

https://forums.4d.com/4DBB_Main/x_User/4028/files/28441297.zip

Roland Lannuzel

Merci pour la babase, Roland, c’est instructif :wink:
On était déjà d’accord, je crois, c’est la subtilité entre DIALOG(…) et DIALOG(…;) que je ne pigeais pas. J’ai retenu qu’une fenêtre ouverte avec DIALOG(…;) peut exécuter pas mal de choses, à l’exclusion de DIALOG - elle est en quelque sorte dédiée au formulaire qu’elle affiche.