On 2017-05-31 23:13, hh via use-livecode wrote:
Call, send , dispatch, do script ...
It is very impressive how the core team can still have all that
messaging in mind while developing LC Builder.
The problem here is what syntax to use in LCS to 'call into a widget' -
widget's need to be able to expose public handlers which can be called
from LiveCode Script (not just properties and events).
Now why not use kind of a mnemonic naming in LCB e.g.
sendHandler <handler> <to object>
callHandler <handler> <of object>
dispatchHandler <handler> <of object>
doHandler <handler> <of object>?
The problem is that all the keywords (naturally) associated with
'calling' something in another context are already taken (i.e. send,
call, dispatch, do) and their context is the script of the object. So:
call "foo" in widget 1
Means send the message 'foo' to the *LiveCode Script* side of the widget
- it is not entirely clear how that could work to mean 'call the handler
'foo' exported by the widget's implementation'.
I've pondered 'invoke' as a new keyword - but I'm not sure how much I
like that, but it would 'fill the gap'.
The other way to slice and dice things is to make it so that any
handlers you want to export to act on the widget internally are added as
'library handlers'. e.g.
widget foo
public handler CopySpecial() returns nothing
... do magic stuff ...
end handler
end widget
Would export fooCopySpecial() as a function accessible from LCS where
you can do:
fooCopySpecial(the long id of widget 1, ...)
Or similar. This is closer to how the engine does syntax - which are all
non-object based functions in C++, which then dispatch to the object.
e.g.
copy widget 1
Ends up calling a C++ function:
MCInterfaceExecCopyControl(ctxt, ptr-to-widget-1)
Which then does:
ptr-to-widget-1->copy()
We could still have
do <script> <in object> [as language]
the default for a browser widget being "as javascript".
Could be used parallel to
doHandler <handler> of <browser widget>
(where <handler> has to be a javascript function name).
This would almost fix the 'overloading' problem of 'do in <browser
widget>'. If we require you to do:
do X in <browser widget> as javascript
If you want to execute the code fragment *inside* the browser widget;
then that means:
do X in <control>
Could be taken to mean execute X as LCS in the context of <control>.
Anyway, a bit more to think on here :)
Warmest Regards,
Mark.
--
Mark Waddingham ~ m...@livecode.com ~ http://www.livecode.com/
LiveCode: Everyone can create apps
_______________________________________________
use-livecode mailing list
use-livecode@lists.runrev.com
Please visit this url to subscribe, unsubscribe and manage your subscription
preferences:
http://lists.runrev.com/mailman/listinfo/use-livecode
