[Tcl-bugs] [ tktoolkit-Bugs-233150 ] window flashes on screen when withdrawn/deiconified

[<no...@so...>]

Bugs item #233150, was opened at 2001-02-19 14:32
You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=233150&group_id=12997

Category: 66. Win Window Operations
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Mo DeJong (mdejong)
Assigned to: Nobody/Anonymous (nobody)
Summary: window flashes on screen when withdrawn/deiconified

Initial Comment:
This problem only seems to show up under Windows.
The bug exists in Tk 8.3.2, I assume it shows
up in 8.4, but I have not tested that under Windows.

This bug actually has two parts. You can sort of
work around the problem by adding calls to update
and update idletasks, but that also causes problems.

Here is a bit of code that brings up a window
after a delay. Try it out and you will notice
that the window is initially mapped with a
geom of 1000x1000, it is then resized down
to the reqwidth and reqheight of the button.

if 1 {
set t [toplevel .t -width 1000 -height 1000 -bg black]
wm withdraw $t
update
pack [button $t.b -text AREALLYLONGSTRING]
after 4000
#update idletasks
wm deiconify $t
}

This problem can be "fixed" by uncommenting the
"update idletasks" call. You might be wondering,
why is the first call to update in there? Well
that is because the Window appears on the screen
for a split second even though it has been withdrawn.
So, the first call to update keeps the window from
appearing for a split second initially, but it
causes another problem. When the window is mapped,
it shows up at 1000x1000 for a split second and
then it gets resized to the reqwidth and reqheight
of the button.

This second problem can be worked around by
the "update idletasks", kind of ugly eh?

What is really odd about this bug is that if
you don't call update at all (the way it really
should work) then the window is mapped correctly
(even though it still flashed before being
put away).


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2001-09-08 18:32

Message:
Logged In: NO 

I took another look at this problem and it
seems to be caused by the call to TkWmRestackToplevel
in Tk_WmCmd from tkWinWm.c. When "wm deiconify" is
called the Window is mapped even though it should
not be mapped until idle. The following patch
seems to fix the problem by moving the call to
raise and focus in on the toplevel to a point
after it has been mapped in the idle callback.
This is Windows only code so there should be no
danger to the Unix or Mac ports. I am not sure
about the correctness of this patch so if someone
could take a look and give me some feedback that
would be great.

Index: win/tkWinWm.c
============================================================
=======
RCS file: /cvsroot/tktoolkit/tk/win/tkWinWm.c,v
retrieving revision 1.29
diff -u -r1.29 tkWinWm.c
--- win/tkWinWm.c	2001/03/30 21:52:56	1.29
+++ win/tkWinWm.c	2001/09/09 01:21:13
@@ -1773,6 +1773,16 @@
 	wmPtr->titleUid = winPtr->nameUid;
     }
     UpdateWrapper(winPtr);
+
+    /*
+     * Follow Windows-like style here.
+     * Raise the window and give it the focus.
+     */
+
+    TkWmRestackToplevel(winPtr, Above, NULL);
+    if (!(Tk_Attributes((Tk_Window) winPtr)-
>override_redirect)) {
+	TkSetFocusWin(winPtr, 1);
+    }
 }
 
 /*
@@ -2313,13 +2323,6 @@
 	    TkpWmSetState(winPtr, NormalState);
 	}
 
-	/*
-	 * Follow Windows-like style here, raising the 
window to the top.
-	 */
-	TkWmRestackToplevel(winPtr, Above, NULL);
-	if (!(Tk_Attributes((Tk_Window) winPtr)-
>override_redirect)) {
-	    TkSetFocusWin(winPtr, 1);
-	}
     } else if ((c == 'f') && (strncmp(argv
[1], "focusmodel", length) == 0)
 	    && (length >= 2)) {
 	if ((argc != 3) && (argc != 4)) {


----------------------------------------------------------------------

You can respond by visiting: 
http://sourceforge.net/tracker/?func=detail&atid=112997&aid=233150&group_id=12997