flex-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Frédéric THOMAS <webdoubl...@hotmail.com>
Subject RE: [FDB] Integration
Date Wed, 30 Apr 2014 15:34:59 GMT
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.doroshko@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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message