On 2017-07-28 18:28, William Prothero via use-livecode wrote:
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.

I think it is mainly the thought process which goes with having to do things in this 'threaded style' - for simple things it is fine, but it can get unwieldy pretty quickly for long running sequences of stuff. From an abstract perspective, at the very least, it *should* be possible to make this more natural (e.g. C# has an 'async' concept - which is basically a bit like out wait but more focused) so that is one angle here.

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.

It is definitely possible - the fact it is not is related to a technical detail in the way the engine interoperates with CEF (and the other browsers). However, being possible says nothing about the difficulty of getting it to work or ensuring it continues to work!

The HTML5 engine IS synchronous so that gives at least a suggestion that is should be possible (although, admittedly, the HTML5 engine IS JavaScript so there's no 'world-boundary' to be concerned about in that instance).

At the end of the day, it might not be that making it synchronous *is* the solution, but instead tweaking engine syntax and semantics to make it easier to deal with this asynchronicity.

e.g.

on mouseUp
  async do "..." as javascript into tVar
  -- implicit wait until tVar has been set
  put tVar into field 1
end mouseUp

Note, this is just pseudo-code for the idea. The hardest part about doing the callback thing is that it splits up the critical sequence of actions you are trying to code into lots of bits separated by cruft (the handler definitions). This reduces readability, and maintainability which is something we really don't want. i.e. The problem you are trying to solve is obfuscated by the technical baggage needed to solve it.

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

Reply via email to