Forcing a form execution cycle

I would like to force one execution cycle in the form method of a floating window (DIALOG *), and am drawing a blank on how to do it conveniently.

The window is not the frontmost window, so POST OUTSIDE CALL does not help.
CALL FORM doesn’t trigger a cycle through the form’s method.
CALL SUBFORM CONTAINER has the right idea, but can’t be used here.

Is using SET TIMER the only option in this case?

Thanks

: Keith CULOTTA

force one execution cycle

What are you trying to accomplish after the execution cycle occurs?

Code in a floating window may update the window to reflect what’s happening in the main window. So when there is a change in the main window, it would be nice to just run through the floating window’s code.

BTW, I may have misinterpreted the docs. POST OUTSIDE CALL calls all the floating windows too.
So, one solution is to have in the main window:
<code 4D>
If (Form event#On Outside Call)
POST OUTSIDE CALL(Current process)
End if
</code 4D>

could you be so kind as to elaborate what you mean by

“CALL FORM doesn’t trigger a cycle through the form’s method”

because it must be something more complex that what’s done in this straightforward example:

https://forums.4d.com/4DBB_Main/x_User/298210/files/30163033.zip

I know, for example, that a CALL FORM to a window that is displaying a sheet window over it (thus modal) is deferred until the sheet is closed; but I don’t think there is anything that blocks a call to a palette window running a DIALOG(*)

If the command “BEEP” is put into the form method of form 2 and all events are checked for form 2, no sound is heard when an option button in form 1 is clicked. CALL FORM’s method executes within form 2, but form 2’s own method does not.

I can see where a form method could be put into a project method, and then be called by CALL FORM to emulate triggering a form event equal to zero.

I’m wondering if there is a way to trigger a form event in a specific window like CALL SUBFORM CONTAINER does, only from the “outside”, like CALL FORM($winNum;*) might for instance.

17.2 build 17.237671 macOS 10.14.5

Just noticed something.
When running form 1 in the application process, closing the main window does not close form 2’s window, and the remaining floating window will not close when its close button is clicked.
When running form 1 from a new process, closing the main window closes form 2’s window as advertised.

you are right in that CALL FORM is not designed to “invoke” a form method.

for that matter, nor is CALL SUBFORM CONTAINER,
it simply translates the form event that is already running in the subform, it does not create one.

only a form event can invoke what you call an “execution cycle”
(you are somehow ruling out CALL FORM which is the real deal)
so yes,
you must count on a classic form event like On Outside Call or On Timer.

Then CALL FORM it is.

Also, I see your point about CALL SUBFORM CONTAINER.

Many Thanks,

A turnaround is to use a method called by the form method (“form manager” method). Schematically:

//form method of myForm
myFormManager(current form name)

//myFormManager (entryPoint_t)
$entryPoint:=$1
case of
:($entryPoint=“myForm”)
case of
:(on load)
:(on unload)
end case
:($entryPoint=“myButton”)
:($entryPoint=“myPopup”)
end case

Then using CALL FORM becomes easy:
CALL FORM ($windowRef;“myFormManager”;…)

: Keith CULOTTA

Just noticed something.
When running form 1 in the application process, closing the main
window does not close form 2’s window, and the remaining floating
window will not close when its close button is clicked.
During some recent tests with workers + more than one window in the same process + CALL FORM, I noticed too that the main process does not behave as those created with New process. I think it’s wise not to use the main process, too different from others…