"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 all... Bye, Axel.