HTML5 deployment: progress comes into sight

[Roger Eller]

LOL @ invoke!  You need to rename Widgets to Spells.  #widgetcraft

~Roger

On Jun 1, 2017 6:28 AM, "Mark Waddingham via use-livecode" <
use-livecode at lists.runrev.com> wrote:

> 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 ~ mark at livecode.com ~ http://www.livecode.com/
> LiveCode: Everyone can create apps
>
> _______________________________________________
> use-livecode mailing list
> use-livecode at lists.runrev.com
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-livecode
>