FreeLists / haiku-appserver / [haiku-appserver] Re: progress and status

["Stephan Assmus" <superstippi@xxxxxx>]

Hi Stefano,

> >With regard to ButtonWorld... I have not personally tested >it. From 
> >time to time I try out People. The problem with ButtonWorld >might 
> > be 
> >related to synchronous controls versus non-synchronous >controls 
> > windows 
> >(I say that without having looked at the source even). I >don't 
> > think we 
> >support the (deprecated) synchronous way of things too well. 
> 
> Yes, I'm sure too that the cause is that one. I thought that the 
> cause
> was in BView::GetMouse(), but instead looks like we don't get 
> _UPDATE_
> messages at all while we are in a polling loop in MouseDown(). BTW 
> could
> be related to the problem you (Stephan) have been working around with
> the latest changes (Flush() in TextView).

I'm not sure about that. Several things: Usually, it is not good to use 
drawing commands outside of Draw() or to call Draw() directly. Instead, 
one should always call Invalidate(). On R5, there is some behind the 
scenes magick, that makes sure that your Draw() function gets only 
called as often as your app can manage, no matter how often you call 
Invalidate() in different locked states. If you call Draw() directly, 
you don't take adventage of that.

That being said, I think that the code is correct for the synchronous 
controls version. If we block the window message loop, we obviously 
don't have Draw() called for us, so we need to call it directly. Not 
using B_ASYNCHRONOUS_CONTROLS windows is long deprecated, but I know we 
need to support it nevertheless.

In our BView implementation, I think that the different drawing 
commands don't flush the app_server link. They simply place a message 
into the queue. The command doesn't get executed until something else 
causes the queue to be flushed. In the drawing methods, I think we 
should differentiate wether we are currently called from within Draw() 
or just like that. In the later case, we should automatically flush. I 
don't know how R5 handles this. I know that you need to Sync() a BView 
that is attached to a BBitmap. But for normal views, I never need to 
sync anything, but I don't call drawing methods outside of Draw() in 
any of my apps, so I don't have any experience with that.

If blocking inside MouseDown(), the messages from the app_server should 
still be appended to the queue, and if this does not happen, then its a 
bug. Do you want to investigate this? Of cause they are not dispatched, 
but at least they should be appended, and UpdateIfNeeded() should do 
something.

Best regards,
-Stephan