I've seen CALL FORM come up in some recent threads where people have
mistaken ideas about how it works. I think that the mistakes are entirely
natural when coming from CALL PROCESS/On Outside call. I was going to add
some comments to the docs, but I just looked and don't see how you do it.
Presumably there's something you need to log into first (?) Instructions
appreciated. For now, here are a few notes:
Q: What form event is triggered by CALL FORM?
A: None.
Q: How does the form method know it's being called via CALL FORM?
A: Trick question. The form method isn't called. You specify what method is
called in the CALL FORM command itself.
Q: What does CALL FORM have to do with CALL PROCESS and On Outside Call?
A: In most cases, it replaces them with a superior mechanism. The old tools
still work, but CALL FORM offers a lot more possibilities and much better
reliability and control.
That's some basic stuff - and I think I'm just highlighting what the docs
already say. Conceptually, I think it's helpful to think of the command as
CALL FORM WINDOW
The "message queue" (see more below) *does not belong to the form.* When
you CALL FORM, *it is not the form that catches the call.* You can prove
this for yourself pretty easily. Here's a write-up I sent to Thomas Maul
for comment:
C_LONGINT($winref)
$winref:=Open form window("MyForm")
CALL FORM($winref;"MyForm_Setup";"Call form method parameter")
DIALOG("MyForm")
The queue is able to receive a message as soon as the window is defined and
before any form is associated with the window. That’s fine, but I wondered
about processing sequence. I tried it out and here is what I found:
* You can post a message to the queue before the form is opened (as in your
demo.)
* On Load executes.
* Then the pre-posted message is executed.
If you post a message to the queue from within On Load, then it is executed
after the message posted before the form was opened.
All of this behavior seems perfectly sensible to me, but it isn’t
documented one way or the other. Is this sequence of events something that
we can rely on? I expect that some 4D developers using this tool are very
likely to find it important exactly how On Load and the queue are sequenced.
Thomas very kindly got an answer about this from 4D Engineering. I think it
translates more-or-less exactly as "yes" ;-) So, this is a reliable
behavior:
* Open window
* Post calls with CALL FORM _even though there is no form_
* Load a form
* Post more events in On Before
* On Before finishes
* The calls posted _before_ the form opened run
* The calls posted _within_ On Before run.
Confusing? A little, but try it out - it's not bad at all. Here's what I
recommend:
* Open window
* Open form
* Run On Before and do what you need directly
Much easier to follow.
A bit more about the 'queue'. A message queue is normally a block of data -
think a bunch of parameters formatted as JSON, in some binary format, XML,
etc. That's not what 4D's "messages" are, they're commands. In fact, the
best names for the new commands are probably these:
EXECUTE METHOD IN WINDOW
EXECUTE METHOD IN WORKER
That's what's really happening. When you call a window or a worker, you're
pushing a line of code over for execution *within* that worker or window.
So, the code comes from the outside and is executed in the context of the
target window or worker. It has nothing to do with the form itself, from
out point of view.
There's a ton more to say about all of this, but that's all I've got time
for now.
Questions, comments, and corrections are very welcome. I think that these
new commands are great and that people should get excited about them. Just
playing with them for a couple of hours when you're relaxed is probably
enough to give you the bug. So, please, kick off questions and thoughts -
there are tons of great uses for these commands - I'd love to hear what
people are doing. Particularly simple things. I suck at simple examples...I
tend to write long...but everyone knows that already ;-)
**********************************************************************
4D Internet Users Group (4D iNUG)
FAQ: http://lists.4d.com/faqnug.html
Archive: http://lists.4d.com/archives.html
Options: http://lists.4d.com/mailman/options/4d_tech
Unsub: mailto:4d_tech-unsubscr...@lists.4d.com
**********************************************************************
