From: <no...@so...> - 2001-09-09 01:32:14
|
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 |