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@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 ~ 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 > _______________________________________________ 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
