Jose Alonso <[EMAIL PROTECTED]> writes:
> I think one possible solution to avoid this case is
> the attached patch. (I think it's safe to remove
> unconditionally a message that will be dispatched).
Yes, that looks like a reasonable fix.
--
Alexandre Julliard
[EMAIL PROTECTED]
On Thu, 2005-04-14 at 20:44 +0200, Alexandre Julliard wrote:
>
> The WM_TIMER cannot "remain in the queue", it's never put there in the
> first place, it's generated on the fly. If you really see a WM_TIMER
> in the posted message queue, it's because someone has done a
> PostMessage on it, and th
Jose Alonso <[EMAIL PROTECTED]> writes:
> Yes, the first time that PeekMessage (1) is called, the timer message is
> handled by find_expired_timer, but the timer is not restarted because
> the parameter PM_NOREMOVE is set.
> The WM_TIMER message remains in the queue, and next time the
> PeekMessag
On Thu, 2005-04-14 at 19:49 +0200, Alexandre Julliard wrote:
> WM_TIMER messages are not posted, so the message can't possibly be
> removed by get_posted_message. It will be handled in
> find_expired_timer, which will return a new message and restart the
> timer.
>
Yes, the first time that Peek
On Thu, 2005-04-14 at 15:53 +0200, Alexandre Julliard wrote:
> Jose Alonso <[EMAIL PROTECTED]> writes:
>
> > for (;;)
> > {
> > (1) if (PeekMessageW( &msg, 0, 0, 0, PM_NOREMOVE ))
> > ...
> > {
> > (2) DispatchMessageW( &msg );
> > }
> >
Jose Alonso <[EMAIL PROTECTED]> writes:
> for (;;)
> {
> (1) if (PeekMessageW( &msg, 0, 0, 0, PM_NOREMOVE ))
> ...
> {
> (2) DispatchMessageW( &msg );
> }
> if (!fEndMenu) fRemove = TRUE;
>
> /* finally remove message from t
If a Menu is accessed and the application used the function
SetTimer, then the application and the wineserver use 100% of
the CPU (loop of sending and receiving WM_TIMER).
function used: SetTimer(NULL, 0, 100, TimerProc)
Description of the loop:
dlls/user/menu.c
MENU_TrackMenu
while (!fEndMe
