Christopher Armstrong wrote: > Hi > >> I am not sure if capturing the mouse is a great idea. I understand that >> we have the problem with Windows of not getting a mouse up event when >> the mouse leaves the current window. But this should be handled on >> another level. In most cases we are not interested in a mouse up, so why >> always capture it? This could disturb the interaction with other >> applications. >> > I believe we are interested in the mouse up event. The key problem is > that mouse up events are expected to be sent when the mouse is released > outside of the window it went down in i.e. > > 1. mouse goes down in our window > 2. user holds button down and moves the mouse outside one of our windows > 3. user releases the same mouse button > > This particular scenario is used for popupbuttons at least. IMHO > capturing the mouse for this scenario is reasonably safe; every windows > application does it for menus in order to determine if the user clicks > outside their window. We need it to track this particular set of events > as it is expected by our UI. > > If you read the Cocoa docs carefully, you will notice that mouse up > events only get sent when a mouse button goes down in one of your > windows (it doesn't get sent in other scenarios). Capturing the mouse in > this way emulates the appropriate event handling. The only other way is > to install a hook DLL, which is too extreme. >
I did understand all this when writing my mail :-) Still I think it is dangerous to steal mouse events that are not meant for our application. Perhaps it would be better to move the capture into the trackMouse:inRect:ofView:untilMouseUp: method on NSCell (if the falg is YES). This seems to be the only place where this is valid. On the other hand, if you have a proof that your code will never have any negative outside effect then share it with me. >> As for the change in windowbacking:, I could prove to you that it is not >> needed. But if you feel more comfortable with explicit code, it is fine >> for me. >> I feel a bit uncomfortable with the change to invalidateWindow(). This >> looks like a potential recursion problem. The back end here asks the >> front end to do some drawing and this of course will ask the back end to >> do it. I think it wont loop, but still it looks a bit dangerous. Perhaps >> some simplification and documentation of the code would help here. >> It looks like invalidateWindow is now only used in >> decodeWM_PAINTParams:::. So why not move the code to here? >> > The main reason for forcing a redraw is that the window has been > resized, and the frontend thinks it can hold off redrawing until the > resize event loop is over, which is correct on many other platforms, but > incorrect on Windows when full redraw during resize is sent. During > WM_PAINT, the window is expected to redraw itself, so that's why I > forced it here. The reason for keeping track of whether the backing > store is empty is that we don't want to blit a blank backing store onto > a window that has just been invalidated anyway. OTOH could you explain > how a recursive loop may occur? Is it possible that the frontend would > try re-enter the runloop whilst it is redrawing? > No, I don't think so. I was just not sure, what may cause a WM_PAINT message. If this never gets triggered by our code, only by a resize, then the code is valid. Cheers, Fred _______________________________________________ Gnustep-dev mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnustep-dev
