fjlim@garnet.berkeley.edu (10/29/89)
It appears that the 6.1bX MultiFinder (I am using 6.1b9) will occasionally have problems with mouse moved events. The mouse moved event appears to get stuck in the event queue: the mouse moved event gets generated, but doesn't get returned by WaitNextEvent until some other event, such as a keystroke or mouse click, occurs. This situation frequently happens after dragging a window, resulting in the cursor not being changed to the proper shape when it enters the content region of the window. This bug can be seen in the ArtClass demo program which comes with THINK C 4.0 as well as the TESample program from Mac DTS. By setting proper breakpoints (I did this in THINK C), you can observe the following behavior: Repetitively drag a window and move cursor inside the window. Eventually, the cursor will not change. Wait a minute or so, then hit a key. With proper breakpoints, you will see that a MouseMoved event and then a keyDown event are returned successively by WaitNextEvent. Look at the when field of both events: the time difference will be how long you waited before hitting a key. The MouseMoved event was stuck in the queue until the key was hit. This behavior is observable because both ArtClass and TESample use a very long sleep time (2^32 - 1) for WaitNextEvent. Kent Borg sent me e-mail and noted that the cursor update problem with ArtClass running under MF 6.1bX does not occur if a DA is running in the DA layer. I guess that's why it's still Beta. Anyway, to the folks at Apple, please consider this as a bug report. Greg Dow