Adi Oanca <adioanca@xxxxxxxxxxxxx> wrote: > Axel D=F6rfler wrote: > > > - only BWindow's thread must be allowed to dispatch messages. > > > (This > > > method should just query app=3D5Fserver if called with > > > checkMessageQueue > > > =3D3D true from another thread - IMO. We should check how R5 > > > behaves > > > on this one.) > > Nope, there is no reason for that. > Well... yes, there's no real reason to do that. However, to me, > it doesn't sound right to execute the update process from another > thread > than BWindow's one - that's the main reason for this thread isn't > it=3F. Yes, you might be right with this one. As you might have already seen, UpdateIfNeeded() only processes the =5FUPDATE=5F messages when it was called from the looper's thread. However, this can still be problematic as you potentially block the thread the same time you'd do from its own thread, we might still need to change it back (ie. change UpdateIfNeeded() to process these messages from another thread). But we can postpone this decision when actual problems arise, I guess; after all, BView::GetMouse() is probably only rarely called this way (although I could imagine that ported single-threaded apps would do it this way). > >>- BeBook says: "his function first looks in the message queue for > >> any pending reports of mouse-moved or mouse-up events" yet you > >>discard B=3D5FMOUSE=3D5FDOWN also. Why=3D3F > > Because if you wouldn't get those, GetMouse() would not work > > correctly; > > the documentation is wrong here. > Well... I just asked. You who programmed BeOS a lot more than I > did, > know better. It's not even that complicated; if GetMouse() wouldn't catch B=5FMOUSE=5FDOWN events, it could never tell you when the user pressed another mouse button. That's certainly not what you'd want or expect. > >>- "where" field from any B=3D5FMOUSE=3D5F* message contains a point > > > that's in > >>screen coordinate system, conversion to local coords is needed. > > I don't want to frighten you, but that's not compatible to R5 here. > > And > > since every application is allowed to peek into that message, I > > think > > we need to change that. > Damn, I was trying to avoid doing that on the server side. > Apparently I > cannot escape this. I just wanted to have RootLayer's thread do as > little as possible, and do the rest of processing in other threads. There would be one hack around that, the "where" field could be added to those messages before DispatchMessage() is called. But of course, that would have to be done always before you call that method (app=5Fserver could add a "screen=5Fwhere" field only then). > > The one in GetMouse()=3D3F Sorry, you're wrong - when I remove it, > > nothing > > is working anymore, the whole app stands still after that. > :-)) Sorry, my fault for not saying the whole story. If you add/ > remove > some data in any BPortLink message on one side (client/server) you > need > to make sure you add/remove a line on the other side (server/client) > in > order to read the new data. Okay, I did that now, and surprise, you were absolutely right :-) > > So much for defensive and robust programming :-/ > BPortLink was not thought to be robust. It was thought to be as > light > as possible. (Be did it almost identically - our method is a bit > better > actually) The fact that Be does it the same way, doesn't mean it's a good way :-) In any case, these things should be handled more gracefully - right now, even the mouse cursor is slow like hell in those cases (not just the window itself). [event mask] > As Stephan asked if someone wants to to something about this issue, > I > can continue doing it and make the event mask stuff work. > Unfortunately > I can't do it in this weekend because I'm out of town. If you can > wait > until Monday... I have definitely no pressure there, I just wanted to mention it. Sure, it would be nice if you could fix it :-) Bye, Axel.