comparison src/event-msw.c @ 923:3b122a8e1d51

[xemacs-hg @ 2002-07-14 23:20:35 by mta] event-msw.c (mswindows_need_event): Don't wait for a new message if the queue is not empty. Suggested by Paul Moore.
author mta
date Sun, 14 Jul 2002 23:20:36 +0000
parents 4a27df428c73
children 8d610ea37af8
comparison
equal deleted inserted replaced
922:0288e82c84b3 923:3b122a8e1d51
1620 (hyphen, VK_SUBTRACT) key on an 82-key keyboard. 1620 (hyphen, VK_SUBTRACT) key on an 82-key keyboard.
1621 */ 1621 */
1622 1622
1623 __try 1623 __try
1624 { 1624 {
1625 active = MsgWaitForMultipleObjects (mswindows_waitable_count, 1625 /* This fixes a long outstanding bug, where XEmacs would occasionally
1626 mswindows_waitable_handles, 1626 * not redraw its window (or process other events) until "something
1627 FALSE, badly_p ? INFINITE : 0, 1627 * happened" - usually the mouse moving over a frame.
1628 what_events); 1628 *
1629 * The problem is that MsgWaitForMultipleObjects only checks to see
1630 * if NEW messages have been placed into the thread queue. So we
1631 * specifically check to see if the queue is empty (using PeekMessage
1632 * with the PM_NOREMOVE flag) before we wait.
1633 */
1634 MSG msg;
1635 if (what_events == QS_ALLINPUT && badly_p &&
1636 qxePeekMessage (&msg, 0, 0, 0, PM_NOREMOVE))
1637 active = WAIT_OBJECT_0 + mswindows_waitable_count;
1638 else
1639 active = MsgWaitForMultipleObjects (mswindows_waitable_count,
1640 mswindows_waitable_handles,
1641 FALSE, badly_p ? INFINITE : 0,
1642 what_events);
1629 } 1643 }
1630 __except (GetExceptionCode () == EXCEPTION_BREAKPOINT ? 1644 __except (GetExceptionCode () == EXCEPTION_BREAKPOINT ?
1631 EXCEPTION_CONTINUE_EXECUTION : 1645 EXCEPTION_CONTINUE_EXECUTION :
1632 EXCEPTION_CONTINUE_SEARCH) 1646 EXCEPTION_CONTINUE_SEARCH)
1633 { 1647 {