deiconify is just plain f*ucked in windows

Mike Clarkson support at internetdiscovery.com
Thu Sep 6 19:10:59 EDT 2001


On Wed, 05 Sep 2001 02:38:22 GMT, gcash
<gcash at luncheonmeat.cfl.rr.com> wrote:
>Except that root.deiconify() just doesn't work under Windows.  
What version of windows? It's the same for me under Win98.

>It'll pop up the first couple of times.  If the window had the focus before
>being iconified, it *might* popup on top.  Otherwise it pops up on the dead
>bottom of the window stack, and lift() doesn't do a goddamn thing.  It just
>sits there blinking the taskbar icon until you flip through and give it the
>focus.
>
>Even though it seems focus related,  focus_force(), focus_set(),
>grab_set_global() don't help.
>
>I tried changing root.deiconify() to root.tk.eval('wm deiconify .') and it
>doesn't make a bit of difference.  Same behaviour.
>
>I thought maybe the original window is "special" in some broken way and
>created my own Toplevel window.  That didn't work.
>
>I tried doing a withdraw() before the deiconify().  No luck.
>
>I looked at Pmw and tried it's setgeometryanddeiconify() and that didn't work.
>
>I went out on Google and tried the:
>        root.iconify()
>        root.update()
>        root.deiconify()
>trick that Guido suggests, and that works about 70% of the time.
>
>I tried a whole bunch of other things that I can't remember right now.

Make sure that on your Toplevel window,
	root.tk.eval('wm overrideredirect .')
returns 0 (it should).

>Now what I want to know is why the hell this is borked in Tkinter when
>deiconify() works just fine as many times as you want in wish or a tcl
>script??????  Why do these things work a couple of times then stop????  
>
>In a tcl script I can "wm deiconify ." all day long and it always pops to
>the front, so it's not a tk bug.  It's a tkinter problem.

It looks like a bug, though I have trouble understanding how and why.
Here's a really curious aspect to this problem, and it's reproducible.

Start a python.exe in a DOS window and do
	import Tkinter
	root = Tkinter.Tk()
	root.tk.eval('toplevel .foo; raise .foo; update')
	root.mainloop()

You get a new toplevel window .foo, that may or may not be on top.
Now ^C out of the mainloop, obscure .foo with any window, and do
	root.tk.eval('after 5000 raise .foo; update')
	root.mainloop()

which says queue up a request to raise .foo in 5 seconds.
The bug then shows itself- .foo is not raised to the top.

Repeat this a ^C/eval/mainloop a few times to convince yourself
it's really really there. Then (if you have a complete Tcl setup) do
	root.tk.eval('package require dde')
'1.1'
	root.tk.eval('dde servername foo')
(you may need to copy tcldde83.dll to the Python Dlls directory).

This loads the Tcl dde server code, and lets you talk to the Tkinter
Tk intepreter using dde. In a normal Tcl wish window, do
	package require dde
	dde servername bar

This lets you talk to the Tkinter Tk intepreter from Tcl wish window.
In wish do
	dde eval foo raise .foo

and the Tkinter .foo toplevel window raises to the top as it should.
In other words, the Tkinter Tk intepreter raises the window just fine,
unless the instruction came from Python.

Now here is the really curious thing: the Python bug has now gone!
Repeat the ^C/eval/mainloop as before and the window .foo always
raises on top as it should. (I'm using Win98B and Tc l 8.3.3 in Python
2.1.0)

It looks like a bug to report to python.sourceforge.net.

Mike.



More information about the Python-list mailing list