I'm using 4.3.0-42 and have noticed that the following minor bug in
multi-window operation when running on Win2K and WinXPPro:
Two windows (terminal or otherwise) are overlapped and the topmost one has
it's Always on top attribute set (by right-clicking on the windows title
bar). The topmost
Mike Parker wrote:
I'm using 4.3.0-42 and have noticed that the following minor bug in
multi-window operation when running on Win2K and WinXPPro:
Two windows (terminal or otherwise) are overlapped and the topmost one has
it's Always on top attribute set (by right-clicking on the windows title
This is probably related: using multi-window mode, open an emacs over
ssh. Click on a menu (e.g, File), leave it droppped down, and minimize
the emacs window. Result: emacs gets minimized, but the dropped down
menu stays behind.
-JT
Hi Mike...
At 08:29 AM 1/25/2004 +, Mike wrote:
I'm using 4.3.0-42 and have noticed that the following minor bug in
multi-window operation when running on Win2K and WinXPPro:
Two windows (terminal or otherwise) are overlapped and the topmost one has
it's Always on top attribute set (by
Earle,
Any reason for the following in your patch:
@@ -893,7 +909,7 @@
if (s_pScreenPriv != NULL)
s_pScreenPriv-fWindowOrderChanged = TRUE;
}
- return 0;
+ break;
The thing that strikes me as odd is that you have to return from the
WM_WINDOWPOSCHANGED message
Howdy Harold, I thought you were taking it easy for a while!
At 11:37 PM 1/25/2004 -0500, you wrote:
Any reason for the following in your patch:
@@ -893,7 +909,7 @@
if (s_pScreenPriv != NULL)
s_pScreenPriv-fWindowOrderChanged = TRUE;
}
- return 0;
+ break;
The
