This is sort of retro post but it came up for me today. I was studying a
component written by someone else and tracing through the good parts to see
how the magic happens. In this case the cool magic happens in a separate
process but the c-obj parameter was loaded up in the method that called it.
No problem, I'll just click over to the Explorer and do Search Callers on
the method name - and find there are no callers. The reason, of course, is
because the method is invoked by New process which takes the name of the
method, not the method itself.
I can do a Find in design to locate the literal instance of the method. I
know that. But it's a little clunky to have to switch search methods plus
such methods appear on the list of 'unused' methods (if you look at such
things).
I handle initiating methods in separate processes within the method itself.
There are two primary forms this takes:
"fire and forget" to simply launch a method in a new process
"persistent" if it's something more controlled
The basic form for a fire & forget method (can be local or process):
case of
:(count parameters=0) // launch method
// could do some error checking here too
$id:=New process(Current method name;Util_get_stackSize;current method
name; Current process)
:(count parameters=1) // actually run the code
// do whatever
end case
And this could have more parameters if needed.
I frequently let users open records into their own process for editing or
viewing. So in this case the I need to be more specific about naming the
new process. Here's a 'persistent' method where $1 is a record id.
case of
:(count parameters=0) // that's an error
:(count parameters=1) // launch method
$procName:=Current method name+"_"+string($1) ` name the process with
the record number
$id:=Process number($procName)
// could do some error checking here or gather other data
if($id=0) // launch it
$id:=New process(Current method name;Util_get_stackSize;$procName $1;
Current process)
else
Bring to front($id)
end if
:(count parameters=2) // actually run the code
$recordID:=$1
// do whatever
end case
I pass the record id in $1. If the user already has it open on his machine
I just bring it to the front. If not I open it. This is also good for
things like "Message viewer" where you only want a single instance running
for the user.
Using a c-obj for $1 opens up greater possibilities. And there's no reason
to use only 2 params. The key is simply using the number of params to
determine how to run the method.
OK, this isn't like a cure for cancer or anything but it sort of follows
the other discussions about setting up code in 4D. The things I like about
it:
- the method's use is 'recognized' and shows up using Search references
- initiation of the method is self contained
- it's easy to do error checking within the initiating process before
starting the new process. Keeps errors closer to their origin
- very easy to identify existing instances and bring to front
- using Current method name is an easy way to avoid issues of language
localization
Performance wise I think it's a wash - not better or worse. The benefits
are simply in the code management.
--
Kirk Brooks
San Francisco, CA
=======================
**********************************************************************
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]
**********************************************************************
