Entry Widget Not Editable under Windows XP with dialog call.

[firatozgul]

BPO	9673
Nosy	@terryjreedy

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2014-05-18.23:16:57.827>
created_at = <Date 2010-08-24.17:49:40.901>
labels = ['type-bug', 'expert-tkinter', 'OS-windows']
title = 'Entry Widget Not Editable under Windows XP with dialog call.'
updated_at = <Date 2021-01-09.00:18:23.998>
user = 'https://bugs.python.org/firatozgul'

bugs.python.org fields:

activity = <Date 2021-01-09.00:18:23.998>
actor = 'terry.reedy'
assignee = 'none'
closed = True
closed_date = <Date 2014-05-18.23:16:57.827>
closer = 'terry.reedy'
components = ['Tkinter', 'Windows']
creation = <Date 2010-08-24.17:49:40.901>
creator = 'firatozgul'
dependencies = []
files = []
hgrepos = []
issue_num = 9673
keywords = []
message_count = 5.0
messages = ['114800', '114805', '114812', '218765', '384701']
nosy_count = 4.0
nosy_names = ['terry.reedy', 'gpolo', 'firatozgul', 'claird']
pr_nums = []
priority = 'normal'
resolution = 'third party'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue9673'
versions = ['Python 2.6']

[firatozgul]

In a Tkinter application that has an Entry() widget on the main window and an askopenfilename() dialog, one should be able to click and type into the Entry() widget as soon as the askopenfilename() dialog is closed. However, the askopenfilename() dialog renders the Entry() widget on the main window unusable/non-editable.

This issue was explored in http://mail.python.org/pipermail/tkinter-discuss/2010-August/002332.html at Tkinter-Discuss mailing list. All details relating to the issue can be followed from there.

It seems that only Windows OS is affected by this issue. In Ubuntu Karmic Koala (GNOME) and Debian (IceWM), at least, this issue cannot be reproduced, and everything works like expected.

[claird]

If it'll help, I can translate this to Tcl/Tk, and report it to the Tk maintainers.

My first impression, which is in the realm of wild speculation, is that this is a Tk defect which has already been corrected. A bit more care in composition of a homologous Tk-coded example should swiftly confirm or falsify that proposition.

[firatozgul]

That sounds nice.

[terryjreedy]

The reverenced post did not give a runnable minimal example with the claimed bug, but only described more complex code at a now dead link. The following from http://effbot.org/tkinterbook/entry.htm works on my Win7 machine.

import tkinter as tk
master = tk.Tk()
e = tk.Entry(master)
e.pack()
e.focus_set()
def callback():
    print(e.get())
b = tk.Button(master, text="get", width=10, command=callback)
b.pack()
tk.mainloop()

[terryjreedy]

My testing was inadequate. From bpo-42867, it appears that 0. the bug is limited to Windows; 1. opening a canned dialog or message box is part of getting the buggy behavior; 2. timing is involved; 3. the bug can be exhibited on Windows directly with wish/tk, so that it is a 3rd party tcl/tk issue and not a tkinter issue. Hence changing the issue resolution.

A workaround mentioned in both the referenced tkinter thread and bpo-42867 is to call after_idle() at some point.