Re: debugging javascript in html5
On 2022-03-18 10:44, Bernard Devlin via use-livecode wrote: Considering the html5 enhancements might well be the biggest thing in LC 10, I can foresee a whole world of pain when it comes to us debugging Javascript interactions. Yes - this is somewhat painful at present - and we do hope to make debugging web standalones in general less painful in time. However, if you 'Test' your web standalone in a browser you can then open up the Developer Tools for the browser you are testing in - which gives you access to the JS console and all the other tools. In JS you can use `console.log(...);` to have messages emitted to the JS console. Additionally, I *think* you can use `debugger;` to have JS code break into the debugger in said browser's developer tools. I must confess I've not tried this myself (as our debugging is usually debugging the engine running in the browser, rather than debugging JS executed from the engine running the browser) - but I can't see why it wouldn't work. 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
Re: debugging javascript in html5
On 2022-03-18 11:19, Bernard Devlin via use-livecode wrote:
Here's a peculiarity I haven't seen mentioned before. I am trying to
test
the viability of the idea of a function to call back to LC and provide
debugging info.
Assume you create a LC function lclog(pmsg,pval) and you put a
breakpoint
in the IDE inside that function body. Set the htmltext of a browser
widget
to the code below, set the javascriptHandlers of the browser to contain
the
word: lclog . Your browser widget will have a button 'clickme'.
1) On clicking that button the JS alerts ALL trigger first.
2) After they have fired the first call to lclog() runs, and the second
call to lclog() never runs.
function lcxhr(method, url) {
alert('lcxhr called');
var json = JSON.stringify({ name: "John", surname: "Smith"});
liveCode.lclog('json created', json);
alert('you see this alert before the above call to lclog()');
liveCode.lclog('exit js function','');
}
So this is quite separate from what happens in the web engine which
works very differently.
Embeddable browsers are inherently asynchronous in their execution (not
necessarily in a multi-thready way, although that does play a part) -
but more in the sense that you can't get an embedded browser to do
anything and have it 'block' until it is done.
The converse is also true - the request to call an LC handler from the
browser widget is basically a post - not a send - which means that
(really) you can only call LC handlers as tail calls - i.e. as the last
thing on a handler.
Warmest Regards,
Mark.
P.S. The web engine is (essentially) the running the LC script 'as
JavaScript' so the same limitation does not apply - calling LC handlers
from JS in the web engine is synchronous.
--
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
Re: debugging javascript in html5
Here's a peculiarity I haven't seen mentioned before. I am trying to test
the viability of the idea of a function to call back to LC and provide
debugging info.
Assume you create a LC function lclog(pmsg,pval) and you put a breakpoint
in the IDE inside that function body. Set the htmltext of a browser widget
to the code below, set the javascriptHandlers of the browser to contain the
word: lclog . Your browser widget will have a button 'clickme'.
1) On clicking that button the JS alerts ALL trigger first.
2) After they have fired the first call to lclog() runs, and the second
call to lclog() never runs.
function lcxhr(method, url) {
alert('lcxhr called');
var json = JSON.stringify({ name: "John", surname: "Smith"});
liveCode.lclog('json created', json);
alert('you see this alert before the above call to lclog()');
liveCode.lclog('exit js function','');
}
http://192.168.0.34:8080/tabs/echo');" />
In case that html gets mangled by the uselist software, here's the above
html base64encoded:
PGh0bWw+PGhlYWQ+PHNjcmlwdD5mdW5jdGlvbiBsY3hocihtZXRob2QsIHVybCkgewphbGVy
dCgnbGN4aHIgY2FsbGVkJyk7IAp2YXIganNvbiA9IEpTT04uc3RyaW5naWZ5KHsgIG5hbWU6
ICJKb2huIiwgIHN1cm5hbWU6ICJTbWl0aCJ9KTsKbGl2ZUNvZGUubGNsb2coJ2pzb24gY3Jl
YXRlZCcsIGpzb24pOwphbGVydCgneW91IHNlZSB0aGlzIGFsZXJ0IGJlZm9yZSB0aGUgYWJv
dmUgY2FsbCB0byBsY2xvZygpJyk7CmxpdmVDb2RlLmxjbG9nKCdleGl0IGpzIGZ1bmN0aW9u
JywnJyk7Cn08L3NjcmlwdD48L2hlYWQ+PGJvZHk+PGlucHV0IGlkPSJjbGlja01lIiB0eXBl
PSJidXR0b24iIHZhbHVlPSJjbGlja21lIiBvbmNsaWNrPSJsY3hocignJywnaHR0cDovLzE5
Mi4xNjguMC4zNDo4MDgwL3RhYnMvZWNoby50Y2wnKTsiIC8+PC9ib2R5PjwvaHRtbD4=
So we can't rely on the timing of anything returned to a javascripHandler.
Moreover, once a javascriptHandler has fired there can't be anything else
that runs. Quite a limitation IMO.
Regards
Bernard
>
___
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
debugging javascript in html5
Considering the html5 enhancements might well be the biggest thing in LC
10, I can foresee a whole world of pain when it comes to us debugging
Javascript interactions.
Without access to all the development tools that come in modern browsers
how is any interaction of any complexity between LC and JS going to be
debugged? I think at the bare minimum there needs to be JS code loaded on
the default page of the html5 app launched from the IDE through which JS
code users would easily/transparently be able to feed logging/debugging
information in _their_ JS code back to the LC app running as html5.
I'm running into these problems already in trying to work out why
libUrlLastRHHeaders() is not returning all headers. I don't think I'm
doing anything particularly complex - yet debugging normal JS in a browser
is easy, debugging in LC is easy, but the LC/JS/LC interactions are a black
box. IMO this lack of insight to what is going on is going to be an
impediment to LC users taking advantage of the new html5 platform. I feel
like I'm working with browsers from circa 1999, before the time of the
Venkman debugger that came from Mozilla.
Even a default JS function
liveCode.log('variable =' + variable)
which was set up to send its parameter to the LC html5 app running in the
browser would be helpful. But TBH I suspect more detailed consideration
needs to be given to this area. I think it was 2015 when the html5
deployment was first released. Seven years later and this is finally
getting to something that could be useful, and which certainly would mark
out Livecode from almost all other development tools.
Maybe others have already worked out how to get insight into what the JS is
doing in the context of a html5 app. If so, I'd be interested to know how
they are debugging these interactions.
Regards
Bernard
___
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
