[haiku-appserver] Re: GetMouse()

  • From: "Axel Dörfler" <axeld@xxxxxxxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: Mon, 30 May 2005 17:38:59 +0200 CEST

"Stephan Assmus" <superstippi@xxxxxx> wrote:
> > > poll, but instead, it just searches the message queue, or gets 
> > > the 
> > > information from the app_server directly. What makes GetMouse()
> > > need to 
> > > use UpdateIfNecessary() is not GetMouse() itself but the context 
> > > it's 
> > > usually used in (MouseDown()).
> >     I'm not too happy with this method. I think it does not respect
> > the logic, in general. I just asked for mouse coordinates, not for 
> > a UI
> > update. The fact is that I can call GetMouse() from everywhere
> > in window's context and not actually wanting to update the UI.
> I agree with Adi. Why is GetMouse() triggering a UI update? Just 
> because it
> is "usually" called from inside MouseDown() of some of our controls 
> if the

It is only triggering an update if a) an update is necessary, and b) 
when it is used to steal messages from the window's input queue.

> window has synchronous controls? Is this even confirmed, that R5 
> behaves the
> same way? May I also remind that our controls don't use Invalidate() 
> but

Actually, I can only confirm that Dano behaves this way, because I did 
my investigations there. I've no reason to believe that R5 behaves 
differently here, but that could be checked.

> call Draw() and Flush() when in synchronous mode (the ones I looked 
> at)? So
> that UpdateIfNeeded() will not even do anything! (_UPDATE_ will only 
> be in
> the queue if Invalidate() was used.)

Exactly, processing _UPDATE_ messages has *nothing* to do with Draw() 
and Flush(). It's only used to update the window contents in case of 
overdrawings (because of window/view movements/resizing).
Maybe our app_server doesn't correctly Flush(), that would explain the 
update lag in synchronous mode.
Although I now wonder why we get an _UPDATE_ message in this case at 


Other related posts: