A couple of things.
* First off, CALL FORM has _nothing_ to do with On Outside Call. The CALL
FORM mechanism doesn't generate an event. (Actually, I have to double-check
that...)
* As John DeSoi summarized elsewhere, CALL FORM/CALL WORKER is just a way
to execute a chunk of code in another process. Well, it can be in the same
process so I guess it's a way to execute a chunk of code in a specific
process/context.
* Yes, you can use CALL FORM to call the current window just as you can use
CALL WORKER to call the current worker. This can very quickly become
confusing. The order of execution in your code no longer follows the order
of your code. You've invisibly attached a block of code to the end of the
current call chain. Confusing.
* Like everyone has said, use a project method. This will work a whole lot
better. And, at that point, you don't need to even use CALL WORKER at the
end. Instead, directly call the method you need. This makes your code a lot
easier to follow and prevents any other events from outside workers from
running when you don't expect. Let's say that your form is called
"DisplayWindow" and your worker is called "Calculator." Let's say what you
want to do is fire off the calculation and then post the result to the
display window.
CALL WORKER("Calculator";"MethodToDoCalculation";"
NameOfObjectCallingWorker";"FormWindowReference")
The worker does its thing and sends back the results using CALL FORM. It
passes back the name of the object that kicked off the process. The worker
doesn't need to know anything about that object - it's just passing back
the reference to let the form handler sort out what just happened. So, the
logic about the form is within the form, not the worker. That's what you
want. "The thing knows about itself." Over in the method that handles the
form, you might have a big case statement for different objects (ugh, ugh,
ugh, ugh), or you might have method calls for specific objects. Either way
you branch or dispatch to the correct code for that particular result and
object. Works great, easily extended. No need to CALL FORM on the current
form.
Yes, this means that you need to promote object logic from object scripts
into project methods. That's a good thing anyway. At least a lot of us have
found that to be the case.
Note that you can generalize a lot of this stuff, if you like. For example,
you can have each of your form objects register themselves in a big
C_OBJECT. As part of the registration, you can include the object name (the
key to finding the object's details) and the name of it's object handler
project method. You can add other properties too - Cannon Smith does a lot
in this direction, keeping filters and so on in meta-data. See dicusssions
and excllent feature request here:
http://forums.4d.fr/Post/FR/19051683/1/19075373#19051684
In this scenario, when your result comes back from the worker, you can
generically look up the handler and run it without a huge case statement,
etc. Depending on your situation, you might also be able to handle other
logic via stored meta data. Such as, going to the area automatically,
firing off related calculations or display updates, and so on.
HTH
**********************************************************************
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:[email protected]
**********************************************************************
