[haiku-appserver] Re: progress and status

  • From: Stefano Ceccherini <burton666@xxxxxxxxxxx>
  • To: haiku-appserver@xxxxxxxxxxxxx
  • Date: 18 May 2005 10:12:11 -0000


> > I would think we are not, as some things (like for example >the blinking
> > caret in BTextView) don't work unless we flush every time.

>       You say that compared to R5?
>       That may be because a ::Flush() is not yet present in >BWindow's
>task_looper() after a message is dispatched.

Ahhh, yes, that's what I was looking for.
So, is there any reason why we aren't doing this ? As I think this would fix 
many drawing problems we're having :P

>       First of all, we need to make sure we are BWindow >thread.

Yes, true, I added the todo item but then I forgot to add the check.

>Second thing,
>take all message from BWindow's port and put them in the >MessageQueue().


>       Then search for B_MOUSE_UP and B_MOUSE_MOVED messages, >and while doing
>so, take the _UPDATE_ message that you may find and dispatch >it. Calling
>DispatchMessage(updateMsg, window) is OK - I don't see any >problem by doing 


>       One thing I don't understand from the current >implementation is why
>*location is not updated with the coordinates found in up or >moved messages?

Because we care about the current position, not the previous position of the 

>Why is it that we just eat up those messages and take nothing >from them? Also,
>we should return if we find one of the two messages, not >continue and ask
>app_server for mouse location.

This is how it was before, but it wasn't correct, because then, those messages 
would still show up in the message queue later, when the function returns.
>       Another thing that is wrong is that when sending 
>message to app_server we attach a "reply port". Why?

I have absolutely no idea. I didn't write that code, it was already there.

Stefano Ceccherini aka Jack Burton
Scegli il tuo dominio preferito e attiva la tua email! Da oggi
l'eMail di superEva e' ancora piu' veloce e ricca di funzioni!

Other related posts: