#805 update idletasks does not update repacked widgets on Windows

[Brent B. Welch]

OriginalBugID: 674 Bug
Version: 8.0.3
SubmitDate: '1998-09-02'
LastModified: '2000-04-09'
Severity: LOW
Status: Assigned
Submitter: lfb
ChangedBy: hobbs
OS: All Windows
OSVersion: NA
Machine: NA
FixedInVersion: NA

button .foo -text "Hello World!"
pack .foo -expand yes
pack propagate . 0
. configure -width 200 -height 200
foreach anchor {center n ne e se s sw w nw center } {
pack .foo -anchor $anchor

# update the display
update idletasks

# wait half a sec
after 500
}

Notice how the update idletasks does not remove the image of the button after it has been repacked. Ick.

Reported on c.l.t by davisjf@gte.net (John F. Davis)
(lfb)

This is a code fragment taken from Brent's book!
--
The work-around is to use 'update' instead of 'update idle'.
The problem is that the redraw of the of the button is
occurring within an idle callback, but evidently the redraw
of the underlying frame isn't. Problem still in 8.2.
-- 12/14/1999 hobbs

[Nobody/Anonymous]

Logged In: NO

Here's another simple manifestation of a similar problem:

>wish
label .l -bg red
frame .w -width 250 -height 20 -bg blue
pack .l -side left -fill none
pack .w -side right
update
pack propagate . 0
update
% repeat these lines to show the bug
.l configure -text "AAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAAA"
update
.l configure -text hi ; update idletasks ; after 1000

Occurs with Tk8.4a4 on Win2000sp2. Lots of ugly 'AAAA'
left behind when the label redraws.

This behaviour causes some unfortunate problems in some
applications I use which need to display lots of messages
to the user (in a 'status bar' type thing). If the
messages come too fast, garbage results, and 'update' is
not a satisfactory solution...

[Vince Darley]

Logged In: YES
user_id=32170

It would be good to fix this annoying behaviour before
Tk 8.4 goes final. "update" is sometimes not a good
workaround, because all sorts of new events start to
appear!

[Vince Darley]

Logged In: YES
user_id=32170

Problem still in 8.4b3. Similar problem seems to occur
on tkaqua (MacOS X), but I believe for different reasons.

[Anonymous]

Logged In: YES
user_id=456242

I have a problem which might be related to this (happens
under WinXP but 98 and Unix are OK). An application doing
a long calculation uses a message box and 'update idletasks'
to keep the user informed of its progress. But if you raise
another window, then the application's main window, the
messages no longer get updated, giving the user the
impression the application has hung.

[Donal K. Fellows]

Logged In: YES
user_id=79902

It looks like a subtle interaction between idle events and
window events, as if the events are necessary for the
correct redrawing of widgets taken from the OS toolkit. The
only possible fix is to use [update] instead of [update
idletasks] and write the application so those extra events
don't cause bad things to happen. The [grab] and [focus]
commands can help here.

IMO, this isn't a bug. It's just life being tough. It'd be
possible to add options to [update] to stop processing of
file events and timer events, but this is unlikely to help
because Tk uses timer events internally for quite a few
things, and many of the "bad" events are actually window
events that the programmer just doesn't want to deal with
right now.

[Peter Caffin]

Logged In: YES
user_id=2029956
Originator: NO

I've tested this with Tk 8.5.2.0.284581 (teapot) on both Debian Linux and Windows XP Pro.

I was unable to replicate the reported behaviour on Linux but it still occurs on Windows.