TkInter: Problem with propagation of resize events through geometry manager hierarchy?

[James Stroud]

Randy Smith wrote:
> The cropping and scrolling works fine.  But when I try to add
> responding to resize events, I get into trouble.  Specifically:
> * When I naively change the size of the image shown to be borderwidth
>   less than the size indicated in the configure event, the size of the
>   image shown grows gradually but inexorably when I start the test
>   app.  (Sorta scary, actually :-})
> * When I fiddle a bit to figure out what the actual difference in size
>   is between the Configure event and the image that can be displayed,
>   I get a vibrating, jagged display of the image.
> 
> Investigation suggests that multiple configure events are hitting the
> label in response to each user resize with different sizes.  I'm
> guessing that when I resize the image in response to those different
> events, that creates new resize events propagating through the window
> manager hierarchy, which creates new configure events, which means my
> handler changes the image size, which ... you get the idea.

I can't test your code because I don't have the test image and for some 
reason it does not recognize a tiff of my own. But, just glancing at 
your code, it looks like a quick-fix would be to set self.zoom to a 
sentinel at the end of refresh() and return 'break' at the top of the 
methods that use self.zoom if it is said sentinel value (e.g. "if 
self.zoom == WHATEVER_SENTINEL: return 'break'). You may also want to 
return 'break' for event responders that should terminate the event 
chain. This is a general technique to stop a lot of unwanted event 
propagation.

James


-- 
James Stroud
UCLA-DOE Institute for Genomics and Proteomics
Box 951570
Los Angeles, CA 90095

http://www.jamesstroud.com