|
From: | Lennart Borgman (gmail) |
Subject: | Re: No refresh of buffer before popup-menu |
Date: | Thu, 22 Feb 2007 18:42:08 +0100 |
User-agent: | Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.9) Gecko/20061207 Thunderbird/1.5.0.9 Mnenhy/0.7.4.666 |
Kim F. Storm wrote:
"Lennart Borgman (gmail)" <address@hidden> 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?
[Prev in Thread] | Current Thread | [Next in Thread] |