Tk Source Code

Under windows, if a child toplevel has a grab and is transient, you can not deiconify the application.

# Better example than words:
package require Tk
toplevel .t
wm transient .t .
grab .t

# Now, click on "Show desktop" button
# You will not be able to deiconify the application

Bug introduced by resulotion of #1847002 ?

Your workaround is excellent!
In fact, it fixes the problem and gives user feedback, but also is easy to use.

Thanks!

I have also hit this bug, and found a workaround by disabling the main window after the the grab:
  grab .t
  wm attributes . -disabled 1

And when releasing the grab:
  grab release .t
  wm attributes . -disabled 0

This also gives a better user experience on Windows: the transient window flickers when you click on the main window.

Indeed, anoying bug and present in tcl 8.5.18 and 8.6.4
Great workaround!
I have put it on the wiki:

[http://wiki.tcl.tk/1432]

Nevertheless would not mind that this is corrected.
Couln't this binding be added for all transient windows (on MS-windows) by default ?

Here is the test description:

Having a transient toplevel window:
<verbatim>
toplevel .c
wm transient .c .
pack [entry .c.e]
grab .c
</verbatim>
and then press the "iconify all" button in the windows 10 taskbar or press "Windows-Key + d" in WIndows Vista to Windows 10.
It is not possible to restore the application, as only the main window (.) is in the taskbar, but restoring it fails.

It is necessary, that the window is transient. Otherwise, it may be restored by its own icon in the task bar.

<p>Don't you think it's strange that this workaround is necessary to avoid such a simple example locking up, just because the user clicks on the "Show Desktop" taskbar button?  Any tk app with a modal dialog is vulnerable to this.</P>

<p>See also tickets <a href="http://core.tcl.tk/tk/tktview?name=2896605">#2896605</a> and <a href="http://core.tcl.tk/tk/tktview?name=3414089">#3414089</a>.</p>

<p>I think that <a href="http://core.tcl.tk/tk/tktview?name=1847002">#1847002</a> was ill-advised.  It's caused more problems than it solved; it's introduced an unexpected and unsafe linkage between the grab state and toplevel deiconify and raise; and it's increased inconsistency in behaviour between windows & unix.  I never found the issue that #1847002 aimed to solve to be a big problem (if I'm understanding it correctly).</p>

The OP states in clt that he uses the following workaround on his dialog library, which temporarily ungrab the toplevel:

    bind Dialog <Unmap> {
        if {[grab current] eq "%W"} {
            grab release %W
            bind %W <Map> [subst {
                bind %W <Map> {}
                grab set %W
                catch { focus -force [focus -lastfor %W] }
            }]
        }
    }

See the thread:

https://groups.google.com/forum/#!topic/comp.lang.tcl/YA2OWAgWzV8