[haiku-appserver] Re: GetMouse()

  • From: "Stephan Assmus" <superstippi@xxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Wed, 1 Jun 2005 11:39:51 +0200 (MEST)

> >     Yes that we know. What I asked, and Stephan seems to ask the same 
> > thing, is why(the reason) do we process update requests in a method that
> > queries for mouse status?
> >     If no good reason emerges, maybe we should remove this functionality 
> > from GetMouse() in R2.
> 
> If update requests aren't processed, the rest of the window/views will 
> also not be drawn when needed.

That's true, but is an expected effect. So every control in blocking mode
should call Window()->UpdateIfNeeded() inside the polling loop, just like
the BAlert class would have to. Doing this work inside GetMouse() is a
mis-placed "convenience" IMHO.

> Lets say you have a synchronous slider, 
> which changes the width of the window it is in. If update messages 
> aren't processed, the window will resize, but not be redrawn. A more 
> common example would be that the slider would send a message which 
> invalidates another view in the same window.

I don't understand. If the slider is blocking the window thread in its
MouseDown() hook, how will messages it sends be processed? The only thing
that would get processed by the "hacky" GetMouse(), that the slider keeps
calling, is if it direclty called otherView->Invalidate(). That's because
_UPDATE_ messages would be the only thing that is processed additionally to 
B_MOUSE_XXX.
And indeed, I remember a situation when I was not even programming myself.
Ingo programmed an app, and somehow we didn't know about
B_ASYNCHRONOUS_CONTROLS yet, or it was not yet available, and Ingo had to
program his own "non-blocking" button class so that messages it causes to
send are processed. Maybe he remembers it better. Ingo?

Best regards,
-Stephan


-- 
Weitersagen: GMX DSL-Flatrates mit Tempo-Garantie!
Ab 4,99 Euro/Monat: http://www.gmx.net/de/go/dsl

Other related posts: