On Nov 14, 2007 3:20 PM, Brian Fisher <[EMAIL PROTECTED]> wrote: > Either another thread or they use the WM_MOVING & the WM_RESIZING to > do work in. Windows does this weird thing where it makes your main > thread be in this tight loop of calling your message handler for the > thing that's going on, but it doesn't return from the dispatchMessage > call or whatever. I have no idea why it does that.
WM_SIZING and WM_MOVING are not generated when the mouse button is down but not moving (though the event loop is still blocked)... with live window resizing and moving enabled (the default since xp afaik) they are equivalent to WM_SIZE and WM_MOVE. FWIW, Carbon on Mac OS X has a similar problem: during menu tracking or window sizing/moving the OS enters an "inner" event loop until the operation is complete... at least the documentation is up-front about it. Not sure what the situation is like with Cocoa. Alex. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "pyglet-users" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/pyglet-users?hl=en -~----------~----~----~----~------~----~------~--~---
