It requires setting up chained handlers on both the LC and JS side, but as long as you structure it well, it is not that bad.
I can tell you that for working with maps, it is essential. Sent from my iPhone > On Jul 28, 2017, at 12:28 PM, William Prothero via use-livecode > <use-livecode@lists.runrev.com> wrote: > > Folks: > As a long term Director developer, I found the use of listeners and callbacks > to be quite easy to implement. I don’t see the problem. > > on myRequest > —send a POST or GET request, whatever, with a callback handler specified. > —display a mask that inhibits new mouse clicks and sets a busy icon. > end myRequest > on myCallbackHander myReturnData > —do whatever you want with myReturnData > end myCallbackHander > > But then again, I’m not a master of javascript, so there may be other issues. > > Best, > Bill > >> On Jul 28, 2017, at 9:16 AM, Jonathan Lynch via use-livecode >> <use-livecode@lists.runrev.com> wrote: >> >> Although I am one of the people calling for more browser widget >> development... >> >> I have my doubts about the ability to make it synchronous with LC. >> >> JavaScript is not even reliably synchronous with HTML5, forcing JS >> developers to use callbacks and event listeners in weird places. >> >> Unless you guys are going to rewrite JavaScript AND HTML, how could this be >> accomplished? >> >> Sent from my iPhone >> >>>> On Jul 28, 2017, at 11:57 AM, Mark Waddingham via use-livecode >>>> <use-livecode@lists.runrev.com> wrote: >>>> >>>> On 2017-07-28 16:47, Sannyasin Brahmanathaswami via use-livecode wrote: >>>> Hence oft-repeated prayer that we get the browser "widget" to become a >>>> true member of the LC message hierarchy, they we can leverage the web >>>> apps eye candy layer (easy to build, responsive, CSS is already done >>>> for us…) with LC powerful framework, so that we don't have to waste >>>> time using JS to get work done, but use it just for "clicking here and >>>> there" while LC does the heavy lifting in the background. >>> >>> I can assure you your 'prayer' has been heard - however, there is a slight >>> chasm between hearing a prayer and being able to act on it (especially for >>> mere mortals, like ourselves ;)). >>> >>> There is a whole (reasonably sized) 'new market' for LiveCode in the space >>> of providing the shell into which HTML5/JS webapps can be placed. i.e. The >>> creation of a native app which wraps a HTML5/JS web-app which then has >>> direct access to all the platform features LiveCode gives you access to (a >>> bit like PhoneGap or Cordova or ... - the fact there are so many of these >>> things suggests that it is a very useful thing that people actually want to >>> do). Now, this works quite well right now - although I do appreciate that >>> the asynchronous nature of return values from the host (LiveCode) does make >>> some things more difficult to do (*although*, it should be pointed out that >>> async something I think *all* other host environments that provide this >>> kind of wrapping have to put up with!). >>> >>> However, as you have may have noticed (from various comments - sometimes >>> positive, sometimes not, mostly not - about CEF) there is a fair bit of >>> technical challenge involved in having a browser widget and keeping it >>> working on all platforms. Now, this is not to say we do not like technical >>> challenges - we clearly do. However, in general, the greater the technical >>> challenge, the greater the resources required to solve it. >>> >>> Such an endeavour *has* to be self supporting - i.e. it needs to generate >>> enough revenue in order to justify its existence. The browser widget as it >>> stands is already taxing us on that front (it is really important, so >>> whilst I sometimes get concerned about the 'money-pit' it sometimes seems >>> to be, one has to remind oneself that some things are a long-term >>> investment). >>> >>> Of course, the above is entirely related to technical issues - there is >>> also the problem of selling LiveCode and this feature into such a space... >>> >>> That old adage of 'build it and they will come' is quite possibly one of >>> the biggest load of bovine-backend-excretion that has ever been uttered. >>> Build it and, well, most people will walk by it, some might look at it and >>> go 'oh that's nice' and walk on, very few will actually take the time to >>> visit it without some sort of cajoling. Unfortunately, this kind of >>> activity (I'm of course talking about marketing) tends to be a great deal >>> more expensive than development (I could make the rather cynical >>> observation that there is a reason why marketing consultant's offices tend >>> to be a great deal 'nicer' than those of computing consultants - but I >>> should probably keep that to myself ;)) and it is only through marketing >>> such things that you can make them generate enough revenue to pay for their >>> seat at the table. >>> >>> So TL;DR version. Yes - Kevin and I would both like to do more with the >>> browser widget as it is actually a really really cool thing (so we hear >>> your prayers - every one). However, right now, we simply don't feel we have >>> the bandwidth (to use a Kevinism) to do it properly in a way where the >>> endeavour can be fully self-supporting. Also, we are already seated at a >>> rather large dinner at the moment (Infinite LiveCode, LiveCode Connect, >>> LiveCodeForFM, Version 9, Maintenance of 8, ...) so perhaps need to finish >>> *at least* one of those courses before we embark on the next (no-one likes >>> indigestion, after all). >>> >>> Warmest Regards, >>> >>> Mark. >>> >>> P.S. By the way, I'm mainly saying all of this to make it clear that we >>> have been listening, we are just not able to act on it at the moment. >>> Please *do* keep poking us about it - as it keeps the idea in our minds, >>> and each time it comes up it causes a re-evaluation. It also helps to >>> remind people that they CAN use LiveCode for this kind of stuff and so >>> should - which is a precursor to being able to convince people who are not >>> 'LiveCoders' that LiveCode might be something they should check out... If >>> only to give them an easier way to ship a 'native' HTML5/JS app. >>> >>> P.P.S. We are also fully away that this 'HTML5/JS' wrapper idea is also >>> very much a gorilla activity - they might come for the wrapper, but stay >>> because of LiveCode. However, one still needs to capture and tame the >>> gorilla first ;) >>> >>> P.P.P.S. Yes - I know it should have been 'guerilla', it is just that using >>> 'gorilla' seemed more fun. >>> >>> -- >>> 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 > > > _______________________________________________ > 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
