Kim F. Storm wrote:
"Lennart Borgman (gmail)" <[EMAIL PROTECTED]> writes:
In that case, use (redisplay t) instead of (sit-for 0) to _force_ a redisplay.
Thanks, I just tested, but unfortunately it did not help.
It was a bug in the update_frame logic.
I have just installed a fix in CVS.
Thank you for reporting the problem!
Wow, how good we have someone here who can find such a nasty little bug
quickly (though I do not know how many hours you spent on this of course).
I have just tested and it works as I think it should. The window is
refreshed between the two chained calls to popup-menu if I call
(redisplay t) before the second popup-menu. BTW Is this the way to do it
now instead of (sit-for 0)?
But unfortunately the other bug (menu title corruption in the second
popup-menu) is still there.
This bug indeed looks a bit serious IMO. I have not been able to
reproduce it clearly before, but with the test code I sent I see it
every time.
What especially bothers me is that this happens during the time the
popup-menu is displayed. At first the menu title is shown, but using the
up/down arrows erases or even corrupts the text shown. It seems to me
that something is wrong with the data structures sent to w32 menu
handler - and that could lead to trouble.
Another small problem seem to be that (sit-for n) still does not work if
I call it before the second popup-menu. Is that a bug?
_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug