Issue 2638: tkSimpleDialog Window Flashing (original) (raw)

Created on 2008-04-15 15:44 by Longorh, last changed 2022-04-11 14:56 by admin. This issue is now closed.

Files
File name Uploaded Description Edit
tkSimpleDialog.py Longorh,2008-04-15 15:44
issue_2638.diff gpolo,2008-07-17 22:34
Messages (7)
msg65519 - (view) Author: Ron Longo Work (Longorh) Date: 2008-04-15 15:44
When a Tkinter window comes up that uses tkSimpleDialog to construct a dialog box, the window first flashes on the screen as an unpopulated top-level window, before being drawn in its completed state. This problem is easily corrected by adding two lines of code to the constructor for class Dialog in tkSimpleDialog.py. The first line of the constructor reads Toplevel.__init__( self, parent ). After this line insert self.overrideredirect( True ). The second line from the last in this constructor reads self.initial_focus.focus_set(), just before this line insert self.overrideredirect( False). That's it. I've attached the revised version of this file.
msg65525 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-04-15 20:01
Isn't overrideredirect only used to enable/disable borders in the window ? Why doing this fix what you described ? Also, make a patch against python-trunk instead of sending the entire file.
msg69874 - (view) Author: Ron Longo (ronLongo) Date: 2008-07-17 05:40
Correct. overrideredirect only enables/disables borders. However, what appears as a "flash" when the dialog box first appears is actually a window with only borders being drawn (no contents). Disabling borders BEFORE drawing anything prevents this "flash". I cannot say if this "flash" occurs on all platforms, but it does occur on all windows XP platforms that I've tried it on. In each of these cases the "fixed" tkSimpleDialog.py prevents this "flash". While not vital to application reliability, this fix does make applications appear more professional.
msg69920 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-07-17 22:34
It would be more appropriate to properly use withdraw and deiconify then. I'm attaching a patch that uses them.
msg69961 - (view) Author: Ron Longo (ronLongo) Date: 2008-07-18 18:00
Excellent! That solution works as well.
msg78640 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2008-12-31 17:45
Dropped for inclusion in python 2.5, but should still be considered for trunk and py3k.
msg83270 - (view) Author: Guilherme Polo (gpolo) * (Python committer) Date: 2009-03-07 02:19
Fixed in r70223 and r70225. Thanks for reporting.
History
Date User Action Args
2022-04-11 14:56:33 admin set github: 46890
2009-03-07 02:19:22 gpolo set status: open -> closedresolution: accepted -> fixedmessages: + versions: - Python 3.0
2008-12-31 17:45:24 gpolo set resolution: acceptedmessages: + versions: + Python 3.0, Python 3.1, Python 2.7, - Python 2.5
2008-07-18 18:00:49 ronLongo set messages: +
2008-07-17 22:34:47 gpolo set files: + issue_2638.diffkeywords: + patchmessages: +
2008-07-17 05:40:22 ronLongo set nosy: + ronLongomessages: +
2008-04-15 20:01:28 gpolo set nosy: + gpolomessages: +
2008-04-15 15:44:12 Longorh create