On 28.05.2014 16:06, Frédéric THOMAS wrote:
AIR users will still have to use the DebuggableWorker class as base
class for their workers and the main app as well though.
I'm not sure we can convince all developers to rewrite their workers,
but I hope no fatal error happens if fdb fails to suspend worker.
I had no problems using it with IntelliJ, waiting for more tests /
feedback from you though :-)
It really seems to work! Please check if I get all correctly:
- I have to suspend at least one worker to be able to send 'break'
command. Fdb suspends/sets breakpoint/resumes other workers if needed,
at the end all workers are in the same state as before break command
- the same about 'delete' command.
- when breakpoint is hit, only one worker is paused.
I have one more request for the IDE integration. Using part of file name
in 'break' command is dangerous, more than one file may match. Even
using full file name is not strict enough: we have a lot of users who
had the same-named files in different packages. Currently IntelliJ IDEA
tries to use file id instead of file name whenever possible, but with
your fixes I start thinking about a different approach. Will it be easy
to support relative path in 'break' command syntax? In this case I'll be
sending path relative to src root, e.g. 'break
flash/display/Sprite.as:99'? Implementation should normalize slashes in
known file paths as I'd like to always pass '/' whereas paths returned
by Flash Player may contain '\'.
I just wonder, is it easily doable to modify the Breakpoint UI like
what is done for Java and adding a combobox to access threads on top
of the Frame list ?
Shouldn't be extremely hard.
Alex
