Statement orders

[Monu Agrawal]

Hi I am making a gui based tool. When user preses a perticular button I
am running a heavy command, before this I want to say user to wait with
a image showing infront of her.
My code is like:
def loadData(self):
top=Toplevel(se lf.parent)
top.focus_set()
self.parent.wm_ title("Loading Data...")

os.system('a heavy command')
os.system('anot her heavy command)
top.destroy()

Now when I apply it, it first runs the os.system commands then it shows
the top level.
I tried with putting sleep just before os.system() it didn't help.
Is some statement reordering going on, or I am missing something?

[Fredrik Lundh]

Re: Statement orders

Monu Agrawal wrote:
[color=blue]
> Hi I am making a gui based tool. When user preses a perticular button I
> am running a heavy command, before this I want to say user to wait with
> a image showing infront of her.
>
> My code is like:
>
> def loadData(self):
> top=Toplevel(se lf.parent)
> top.focus_set()
> self.parent.wm_ title("Loading Data...")[/color]

+ top.update() # flush the event queue
[color=blue]
> os.system('a heavy command')
> os.system('anot her heavy command)
> top.destroy()[/color]

</F>

[David Murmann]

Re: Statement orders

Fredrik Lundh wrote:[color=blue]
> Monu Agrawal wrote:
>[color=green]
>> Hi I am making a gui based tool. When user preses a perticular button I
>> am running a heavy command, before this I want to say user to wait with
>> a image showing infront of her.
>>
>> My code is like:
>>
>> def loadData(self):
>> top=Toplevel(se lf.parent)
>> top.focus_set()
>> self.parent.wm_ title("Loading Data...")[/color]
>
> + top.update() # flush the event queue
>[color=green]
>> os.system('a heavy command')
>> os.system('anot her heavy command)
>> top.destroy()[/color]
>
> </F>[/color]

I had a very similar problem and adding an update call solved it, but
in some tk documentation i read that one should be careful with adding
update calls to callbacks and prefer update_idletask s. in my case the
update method is even called one time before the mainloop is entered,
yet everything seems to work fine, so exactly when is it dangerous to
call update? (or is it dangerous at all?)

David.

[jepler@unpythonic.net]

Re: Statement orders

Here's one case where it's bad to call update.

def perform_longrun ning_calculatio n():
time.sleep(1)
app.update()
time.sleep(1)

suppose you kick this off with a keybinding, such as:
app.bind("c", lambda e: perform_longrun ning_calculatio n())
the calculation takes 2 seconds, and after 1 second update() is called,
possibly to make sure that the user interface is repainted.

But imagine that in the first second, "c" has been pressed. That event will
be handled, and perform_longrun ning_calculatio n will be entered *again*,
recursively. The nesting looks something like this:
app's mainloop
handling keypress
perform_longrun ning_calculatio n()
app.update()
handling keypress
perform_longrun ning_calculatio n()
by calling update_idletask s instead of update, the keypress event is not
handled, so it's impossible to enter perform_longrun ning_calculatio n a
second time.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQC+sJd0 1MZaTXX0RAm8wAJ wJIr7c0mKmPdtoO oozvY06T6hDAACf dcgV
BQGWxacx32Rg6eV Mj1jZMjQ=
=vNvV
-----END PGP SIGNATURE-----

[David Murmann]

Re: Statement orders

jepler@unpython ic.net wrote:[color=blue]
> Here's one case where it's bad to call update.
>
> def perform_longrun ning_calculatio n():
> time.sleep(1)
> app.update()
> time.sleep(1)
>[/color]

would it be advisable to guard against this with something like this?

def perform_longrun ning_calculatio n():
if not app.busy:
app.busy = 1
time.sleep(1)
app.update()
time.sleep(1)
app.busy = 0

or does this have flaws i'm not seeing?

David.

[jepler@unpythonic.net]

Re: Statement orders

> would it be advisable to guard against this with something like this?[color=blue]
>
> def perform_longrun ning_calculatio n():
> if not app.busy:
> app.busy = 1[/color]
[...]
By using that kind of construct, instead of using update_idletask s(),
you force all code to be aware of and manage the app.busy flag.

Another difference is that with the original code changed to use
update_idletask s(), perform_longrun ning_calculatio n *will* be called
twice, the second time after the first one completes. With your code,
it will be called once if the second keypress comes within one second, and
twice if called after one second is up. (though a second update before setting
busy back to false will make it be called only once)

So in also depends on what you want your application to do in these cases.

Jeff

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.1 (GNU/Linux)

iD8DBQFDQEkaJd0 1MZaTXX0RAnAzAJ 92hHz2t6DgV6qQ7 skXbDi+gVAyfgCg hyo/
eUggQQ0eb2NIlON P9et6Opg=
=Fhrq
-----END PGP SIGNATURE-----