Tkinter app 'freezes' when I use after_idle

[Doug Hellmann]

Andrew Markebo wrote:
> 
> | network, it might take a while to come back.  Keep in mind that as long
> | as the program is running your callback code, the display will not be
> | updated.
> 
> *HMM* Ok lets try to sort this out.. Of course the first call to the
>  function is from a callback, when I press the 'go' button a call is
>  made to 'checkfunc'. Last in checkfunc I call
>  self.after_idle(checkfunc) this would stay away from the event??


An overly simplified look at the process flow for a Tk app might look like:

create widgets
enter mainloop:
    look for events (including update)
    if events: 
        call event callbacks (your code)
    else: 
        call idle handlers (your code)


While you are in a callback or idle handler, program control does not go
through the section that allows the mainloop to dispatch a callback. 
Instead, the events that would cause the callback to be called are being
queued up for the next time around the mainloop.

It is possible to shortcut this flow somewhat by using the
update_idletasks() method to make sure that all of the screen painting
calls are made (to handle exposure events).

What you want to try to do with your idle handler is make it run very
quickly, so that you can get in and out before a lot of events start
queuing up and the user notices that the screen is not refreshing. 
After you are done with your processing, you reregister the idle handler
to run again.

> |
> | You could use a file handler to let Tk watch the socket for you (instead
> | of doing your own select).  You would then get a callback when there is
> | data for you to read from the socket.  I've had success with this scheme
> 
> *bonk* I have heard about that, time to take a dig into my TCL/TK book again..

That may be your best bet for this app.  There are cases when doing your
own call to select might make more sense.

Doug