Tk Source Code

If a dialog window is created using a Tk transient toplevel, and is then withdrawn, it can magically reappear when the user looks at the preview thumbnail from the Windows taskbar. It's a Windows problem, which didn't occur in Windows 7 but is present in both Windows 10 and Windows 11.

The attached transient.tcl demo script can be used to see the problem. Show the .popup window, but then close it. Now move the mouse over the icon in the Windows taskbar to show a preview of the main window. The withdrawn .popup dialog reappears. The attached diagram.png illustrates this.

I think this is quite confusing for users. Especially on main windows which may have several associated pop-up dialogs, eg property dialogs.

There's no sign that it may be fixed in Windows, but I have found a work-around described elsewhere. The work-around is to temporarily specify style WS_EX_TOOLWINDOW on the transient window when it is being withdrawn. That stops Windows capturing it in the preview. I have implemented that in the attached win/tkWinWM.c, an update of the Tk 9.0.1 version.

This issue depends on the MS-Windows settings found in:

• Page: Settings->System->Info
• Link: Extended System Settings (German is: Erweiterte Systemeinstellungen)
• Tab: Extended
• First Button on tab: "Visual Effects..."
• Disable the first item "Animation on Maximization and Minimzation of Windows" to not have the issue. Note, that Windows automatically disables this on low-power hardware.

I will attach a screen-shot, unfortunately in German localization.

Harald

Thanks, Francois, I appreciate the review.

Merged by:

• main: "fossil merge 91d0e9d8-mswin-withdrawn-taskbar" [33bad85e]
• core-9-0-branch: "fossil merge --cherrypick 33bad85e" [d33c12c1]
• core-8-branch: "fossil merge --cherrypick 33bad85e" [2d521128]
• core-8-6-branch: "fossil merge --cherrypick 33bad85e" [eff58ccd]

Thanks to cjmcdonald for the patch, test and discussion, I appreciate ! Harald

I believe this can now be merged, thanks.

I have now run the test suite on Window 7 with the updated wish, and it works ok without any differences in the results.

Thanks for the test, great !

If you have a Windows 7, it would be great to run the full test-suite (Tcl and Tk) and report back if all works ok ;-).

May this branch be merged on branches main, 9.0, 8.6 ?

Thanks, Harald

Thanks for the comments, good point about older systems.

I've now been able to test the update on a Windows 7 laptop. Windows 7 never had this problem, withdrawn transient windows remained hidden using the taskbar preview. Testing with the updated wish it still works as expected. And I don't see any other effects - no change to window appearance or anything else.

I wouldn't say that Windows 7 automatically applied the WS_EX_TOOLWINDOW property. It just worked correctly, and was clever enough to not include withdrawn child windows in the taskbar preview. In Windows 10 that cleverness appears to have been lost. And still not fixed in Windows 11. The WS_EX_TOOLWINDOW property is just a work around for the Windows problem, which I saw suggested in another non-Tcl project. It prevents that window from being captured for the preview.

Francois, thanks a lot for the review.

Yes, we also support WIndows 7 and Windows 8.

https://core.tcl-lang.org/tips/doc/trunk/tip/592.md

I have no test system for those any more. But I have clients using Windows 7 in closed systems. In the medical field, this is quite common.

Thanks for all, Harald

I had a look at this and tried the patch. The patch fixes the issue for me indeed (on Win11).

I can understand the rationale of the OP for not having used TkpWinToplevelWithDraw() as Harald suggests. However the only call to TkpWinToplevelWithDraw() is from outside tkWinWm.c, in tkWinEmbed.c and looking at where this call is placed I can't see why withdrawing toplevel embedded windows would need to be handled differently than withdrawing non-embedded windows. Therefore I think there would be low risk of going for using TkpWinToplevelWithDraw() everywhere. Anyway, what is currently done is safe.

Question: While the patch fixes the situation on Win11 (and Win10, I trust the OP), what is it's effect on earlier Windows versions that we still support? Is the behaviour on these earlier Windows versions changed or is the WS_EX_TOOLWINDOW property perhaps automatically set by the OS in some way?

Hi Harald, thanks for sorting the test branch.

You are correct that I could have just extended TkpWinToplevelWithDraw and used it throughout. However, TkpWinToplevelWithDraw is a Module Scope routine called from elsewhere (something to do with embedded window support), and I wanted to leave open the possibility of it doing something different from my new routine. And if a problem with the update emerged then TkpWinToplevelWithDraw could possibly be reverted, but leaving the rest of my changes.

Sorry, mixed-up the tickets, my bad. The patch is now in [9c99081a] within branch [91d0e9d8-mswin-withdrawn-taskbar].

Stupid question: Why create a new function "WithdrawWindow" and not extend the already existing public function "TkpWinToplevelWithDraw" ?

I have tested the branch. If others want to try it, follow exactly the instructions on the attached photo.

The fix is effective and IMHO an improvement.

I also think, this should be back-ported to 8.6 if possible.

Take care, Harald

Hi Harald, thanks for looking at this. Some confusion with the patch I think. I submitted two tickets yesterday:

1. This ticket 91d0e9d8e6 which works-around the annoying reappearing transient windows on Windows taskbar previews. This ticket has an updated version of tkWinWm.c attached.

2. Another ticket [159aa5eba2] which is a simple one-line patch to fix the Windows system menu on transient windows.

I submitted them as two separate tickets because some projects insist on one problem per ticket, and it allows the maintainers to pick and choose what they want to use. Sorry if it led to confusion.

The checkin [99a27136] you have created and linked to below is the one-line patch for the other ticket [159aa5eba2], to fix the Windows menu. Not for this ticket.

To see the work-around for the reappearing transient problem in this ticket it will be necessary to use the attached tkWinWM.c.

My other comment was nonsense. The patch is now in checkin [99a27136] starting branch [159aa5eb-win-transient-system-menu].

I tested it, it is an improvement.

Thanks for all, Harald

I can second, that this is annoying.

I also have another phenomenon, that the update is eventually not up-to-date. When I change a window and directly minimize it, the changes are not in the preview. That is normal, as an "update" must be run in the mean-time.

Thanks for looking into this and the patch.

I think, back-porting to 8.6 would also be great.

Take care, Harald