Update 9/2/2007: in the time since I originally posted this entry, I figured out the problem. Every event dispatched to the McCLIM framework gets a timestamp, and these timestamps must be sane. Whereas before all currently queued events were getting their timestamps reset to the same value, I now make sure that each event is stamped using GFW:OBTAIN-EVENT-TIME. And so the annoying misbehaviors with decoration rendering, sizing, and moving of frames were resolved.
Original text follows:
Over the last several days, I made another attempt to fix event handling in clim-graphic-forms, which is a backend that I started for McCLIM using Graphic-Forms. The problem is hard to describe, but the most visible symptom is that top level windows act like non-client messages are only getting sporadically processed. For example, if I drag a top level window by its titlebar to a new location and let go, it becomes unresponsive to further mouse input until I deactivate and then reactivate the window. Or if I resize a window, the right and bottom frame decorations are not drawn -- even the titlebar doesn't resize. If I comment out the lines of code where I notify McCLIM via window configuration events, then of course McCLIM is prevented from doing what it needs to do, but the window frame starts to behave correctly.
The backend maintains an internal event queue which gets populated by various GFW:EVENT-*** methods and which is drained by CLIMI::GET-NEXT-EVENT. GET-NEXT-EVENT also has the job of retrieving each new message from Windows. I have experimented with several other approaches, including reimplementing CLIMI::SIMPLE-EVENT-LOOP to call GFW:MESSAGE-LOOP directly with a custom message filter that calls CLIMI::HANDLE-EVENT directly. The end result is the same.
I could work on filling in other missing functionality, but this event handling issue really bugs me to the point of extreme frustration. What is it about calling back into McCLIM during an event that causes such problems? I have no idea.