Adi Oanca <adioanca@xxxxxxxxxxxxxx> wrote: > Axel D=F6rfler wrote: > > I've worked a bit on GetMouse(), and I think it's now more or less > > correct. > You're not done yet. :-) We'll see about that :-) > - only BWindow's thread must be allowed to dispatch messages. (This > method should just query app=5Fserver if called with checkMessageQueue > =3D true > from another thread - IMO. We should check how R5 behaves on this > one.) Nope, there is no reason for that. > - you don't need to lock the message queue because you'll be in the > context of BWindow's thread. At least ::task=5Flooper() doesn't do so, > maybe it should. task=5Flooper() doesn't need to do this because BMessageQueue::AddMessage() locks itself. However, we don't want the message queue to change while we're at it, so we lock it. Since GetMouse() (and probably other stuff, too) might change the queue from another thread, this is just what we have to do. > - you don't need to iterate through the whole queue for =5FUPDATE=5F > messages, there's a maximum of one present at a time. Ah, okay, good to know. > - 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=5FMOUSE=5FDOWN also. Why=3F Because if you wouldn't get those, GetMouse() would not work correctly; the documentation is wrong here. > - "where" field from any B=5FMOUSE=5F* 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. That's probably why the app=5Fserver/input=5Fserver knows the target view in R5, too. > The rest is fine, thanks for your time. ;-) > > Oh, one more thing... > owner->fLink->Attach<port=5Fid>(owner->fLink->GetReplyPort()); > needs to go. It's useless. The one in GetMouse()=3F Sorry, you're wrong - when I remove it, nothing is working anymore, the whole app stands still after that. So much for defensive and robust programming :-/ > > It still doesn't work correctly, but this time it's probably the > > app=5Fserver's fault, as we only rarely get =5FUPDATE=5F messages. > Well, maybe with the above changes it will. Yes, indeed, the coordinate change helped a lot :-) It still looks very bad compared to R5 as well as the asynchronous version, but at least it's somewhat working now! BTW: in asynchronous mode, when you press the mouse button over the button (playground app), and then release it somewhere else, the button still changes its status on mouse over (without a button pressed). This doesn't happen under R5, so I guess our event mask stuff is not yet working correctly. Bye, Axel.