Note, you can run the flash debugger on an app that is in the web browser, you invoke it using a url like
fdb "http://localhost:8080/trunk/myapp.lzx?lzr=swf9"; and it will fire up your default browser with the URL, and then sit in the command line waiting for you to set breakpoints, or type "c" to continue. Then you have a command line debugger attached to a Flash app that is running in the browser , so you don't have the resource path problem you mentioned. On Mon, Sep 14, 2009 at 8:24 PM, James Robey <[email protected]> wrote: > P T Withington wrote: > >> [cc-ing Laszlo-Dev, in case other people want to chime in.] >> >> On 2009-09-14, at 19:56, James Robey wrote: >> >> I want to define bomb silently again, to be sure you understand; bomb >>> silently means that the runtime halts the initialization stage at the time >>> of error, often leaving applications completeIy blank and unresponsive, >>> depending on how deep in the API the problem occurs. There is no debugger >>> warning. I've notice a large group of situations where the runtime will halt >>> in this fashion, and because i'd like to help i'd like to ask the following >>> question: >>> >>> Are all of these bugs to be reported? >>> >> >> I think that this bug: >> >> http://jira.openlaszlo.org/jira/browse/LPP-8151 >> >> probably is sufficient for the "bomb silently", problem for now. >> >> I went back and looked at the state of debugger support for catching >> errors and see that I only enabled it in the case where backtracing is on, >> but we don't support backtraces in swf9 yet, so that's basically a no-op. >> In DHTML, you have a similar situation, there are errors that will halt >> Javascript in the browser that would not cause an error in swf8. In DHTML, >> you have to resort to the browser debugger (Firebug, Webkit's built-in, IE's >> add-on), just as you have to resort to the Flex debugger in swf9 to track >> these down. In DHTML, I tried to help a little bit by enabling the catching >> of errors automatically when you turn on backtracing (since backtracing >> needs to establish try/finally blocks anyways), but... You'll see that I am >> prevented from having the debugger always catch errors and report them by: >> >> http://jira.openlaszlo.org/jira/browse/LPP-8222 >> >> so I am trying to come up with a compromise. It will probably be >> something along the lines of Java, where if you mean for a method to be able >> to throw a runtime error, you have to declare it so. >> > I actually read the jira entries, most informative, thanks. > > May I suggest that it be an option along side the debug checkbox in the > tomcat interface? if it's quick to patch it in as a query parameter, the > decrease in testing time would be worth it (to me, right now). Having to > switch and reload flash movies in the flash debugger isn't fun, for number > of actions and since it also means web resources don't act quite the same > (e.g. no url) > > Perhaps you could illustrate briefly how hard a fix like that would be? I > wouldn't know where to start. > > -- Henry Minsky Software Architect [email protected]
