jf...@ms4.hinet.net at 2015/11/29 UTC+8 10:55:28AM wrote：
> > > .....
> > > .....
> > > #do the rest
> > > var_status.set('Download...')
> > > _thread.start_new_thread(td_download, ()) #must use threading
> > >
> > > def td_download():
> > > result = mydll.SayHello()
> > > if result:
> > > var_status.set("Download Fail at %s" % hex(result))
> > > showerror('Romter', 'Download Fail')
> > > else:
> > > var_status.set('Download OK')
> > > showinfo('Romter', 'Download OK')
> >
> > As td_download() runs in the other thread the var_status.set() methods are
> > problematic.
>
> No idea what kind of problem it will encounter. Can you explain?
It might be not a good idea to update GUI in a spawned thread, according to
Mark Lutz's book "Programming Python", section "Using Threads with tkinter GUIs"
"If you do use threads in tkinter programs, however, you need to remember that
only the main thread (the one that built the GUI and started the mainloop)
should generally make GUI calls. At the least, multiple threads should not
attempt to update the GUI at the same time..."
> > Another complication that inevitably comes with concurrency: what if the
> > user triggers another download while one download is already running? If
> > you
> > don't keep track of all downloads the message will already switch to
> > "Download OK" while one download is still running.
>
> Hummm...this thought never comes to my mind. After take a quick test I found,
> you are right, a second "download" was triggered immediately. That's a shock
> to me. I suppose the same event shouldn't be triggered again, or at least not
> triggered immediately, before its previous handler was completed. ...I will
> take a check later on Borland C++ builder to see how it reacts!
>
> Anyway to prevent this happens? if Python didn't take care it for us.
then don't use thread if you prefer the GUI freeze.
--
https://mail.python.org/mailman/listinfo/python-list
