mlange at widged.com
Wed Oct 25 10:36:16 EDT 2006
> When a handler calls another handler or a function I put a special
> and short comment at the end of the line to tell me where is this
> handler or function
> Galaxy's script editor lets you right-click the name of a handler
> calling and brings its script right up for you... absolutely love this
I do this even more explicitly. I don't put handlers in the stack or
card script anymore. I put them in a group on a library card. I use
the group as a small component library. I have the code for the
component in the group and I have code for testing the code of that
component in small bug-like icon within the group. This way, I can
easily move my component from one stack to the other and when I do
so, I am always certain to move the test suite along with the code.
With that solution, anytime I use a handler calling to that library
from outside that library, I am forced to write :
send apihandler to tAPI_reference
where tAPI_reference has been set to something of the like:
put the long id of group "api_dosomethingfantastic" of card 1 of
stack "thisproject_libraries" into tAPI_reference.
You will tell me then that there is a problem... I can only call
handlers, not functions this way. Well there is an unfriendly syntax
to call functions. I avoid it and I write my call this way:
In the calling script:
put the long id.... into tAPI_ref
set the param1 of tAPI_ref to valueA
set the param2 of tAPI_ref to valueB
set the param3 of tAPI_ref to valueC
send apihandler to tAPI_ref
wait 1 tick -- probably not needed, just to be absolutely sure that
the api has finished its processing.
put the output of tAPI_reference into tResult
In the API library script:
put the param1 of me into tParam1
put the param2 of me into tParam2
put the param3 of me into tParam3
put apihanndler(tParam1, tParam2, tParam3) into tResult
set the output of me to tResult
function apihandler p1, p2, p3
-- do something with p1, p2, p3
Of course this forces me to write my apihandler code in such a way
that it only relies on code within the api for proper working... or
at worst only call to a very limited number of other APIs. Well
that's a good coding practice, isn't it!?
Similarly, to overwrite the function call with the handler call adds
a bit of code. But on the other hand, this makes the input and output
parameters of the function highly visible... It provides me an
unambiguous description for my API. And then because the values are
stored within custom properties, this means that I can rapidly and
easily design a small UI on the screen to let the user directly
change and manipulate the data that this function processes.
The best of all, there is never any conflict with other libraries. I
don't put anything in the back of front. I simply start call to a
component and the code runs strictly within that component.
Let me know what you think. This works brilliantly for me!
Marielle Lange (PhD), http://widged.com
Bite-size Applications for Education
More information about the Use-livecode