Ah I guess I see your point now, correct me if I'm wrong, you have the need to
be able set a BP before the next break event, right ?
If it is the case, not sure I can do many things, I don't think I can catch a
worker status change until I receive a myself break event, I check it though.
I plan B is quite awful, it would be you would wait for the next break event
and set the BPs as you do it usually but it means as well that 1 occurence of
the break event on this BP might be uncaught if the BP is set before the next
already registered to break.
Frédéric THOMAS
> Date: Wed, 30 Apr 2014 19:24:58 +0400
> From: alexander.doros...@jetbrains.com
> To: dev@flex.apache.org
> Subject: Re: [FDB] Integration
>
> On 30.04.2014 19:20, Frédéric THOMAS wrote:
> >
> >> You are right, suspending all running workers that contain the file,
> >> setting breakpoint there (and probably resuming?) seems to be the best.
> > Sure resuming it if I halted it.
> >
> >> Unfortunately some workers may fail to suspend if they are doing
> >> nothing. In the latter case breakpoint could be remembered and set when
> >> worker gets anything to do.
> > If you have an example of that behavior, give it to me please as I guess in
> > that case, I can still set the BP, etc.. without the need to halt it or to
> > be more precise after it failed to halt.
> BackWorker in the example we played with can't be halted unless you
> select a file for it in the main thread. You reproduced it yourself
> yesterday when you wrote following:
> > Bug 2: Can't halt the player execution, it tells me to click a button,
> > what I do but failed to halt it
>
