Hi, >>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. > > Ok, agreed. > >>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 just had a small discussion with Marc Flerackers about that. I had long ones about 2 years ago. :-) > He said that r5 flushes the command buffer every time a reply is needed > AND PERIODICALLY (probably in the looper thread). Yes, in the looper thread too. A flush occurs when: - Flush() or Sync() is called. - when the current message that is being composed does not fill in the remaining space of the send buffer. (complete commands that are in this buffer are sent and the one being constructed is copied at the start of buffer - at least that's how I remember it) - some commands need to stay in sync with the server and in their body (Bounds() for example) they flush the buffer and wait for a reply. - Sync() is/will be called after a message (any) is dispatched in BWindow's thread. > R5 can do that because > graphic messages aren't really messages, but instead, there is a stream > of commands. That's one of the reasons why BMessages weren't used for > this task: Bmessages need to be completed before being sent (there is no > support for incomplete BMessages), a stream of commands does not need to: > the app server can just start drawing as soon as it gets the first command. We have better. Our messages will be buffered just like in R5, but what's nicer is that they are complete. > That's a big difference from what we have, because BPortLink still > sends/receives complete messages. I don't know if we can flush the ports > periodically too, and what would happen if we started doing that. We can. And we do that. ;-) > Note: I suggest you to speak with Marc as he's the guru in there, > this is just what I've understood :P You can talk with me and DW as we both know pretty well how this stuff works. >>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? That's not a bug, because it's not possible. BWindow thread is in task_looper()->DispatchMessage()->MouseDown() and it's blocked here until MouseDown() returns. What happens is, messages from the server (and other threads) will enqueue in kernel's port queue that BLooper created. (have a look at BLooper::task_looper()) I'm afraid I do not understand the discussion you guys are having. (I need to remember you I haven't programmed BeOS very much) So excuse me for asking: What is your problem? What do you need? You need to have UpdateIfNeeded() working, or what? To implement this method we need to enqueue all messages from BWindow/BLooper's port into BLooper's MessageQueue() and search for _UPDATE_ message. There must be only one! Then simply do exactly what BWindow::DispatchMessage()::case_UPDATE_ does - call Draw() where it's needed. In other words: we take the _UPDATE_ message and process it NOW! (Another approach: put all message for BWindow's port in BLooper's MessageQueue(), search for _UPDATE_ message, pull it out from MessageQueue() and call DispatchMessage(updateMsg, Window()); ) Hope this clears things a bit. If I'm totally off, then please explain what is it you want. Thanks, Adi.