Anonymous Monk has asked for the wisdom of the Perl Monks concerning the following question:
|
|---|
| Replies are listed 'Best First'. | |
|---|---|
|
Re: Executing functions in Perl::Tk
by liverpole (Monsignor) on Feb 24, 2010 at 00:49 UTC | |
The really simple approach is just to call the method update() on the main window object at appropriate times during the subroutine execution:
The more complex (but very powerful) approach is to use threads, as long as you're very careful not to do anything Tk-related within the thread. (That's because Tk is not "thread-safe"). Here's an example of a way you could use threads, especially if there are parts of the worker subroutine that have long delays during which you don't have the luxury of using $mw->update:
Please note that once you're in the worker thread, you must refrain from the urge to use Tk. If you want to pass data back to the main program, you should look into shared data between threads. If you try putting back in the code where it says "But DON'T do this", you'll get an error message like:
s''(q.S:$/9=(T1';s;(..)(..);$..=substr+crypt($1,$2),2,3;eg;print$..$/ | [reply] [d/l] [select] |
|
Re: Executing functions in Perl::Tk
by zentara (Cardinal) on Feb 24, 2010 at 12:55 UTC | |
For instance, the code in liverpole's example where the thread is created in a button callback, after Tk code has been invoked in main, has a possible problem. Many nodes have been posted previously, on how some of the "copy-on-write" Tk code gets copied into the thread, and sometimes causes "free to wrong pool" errors. The example works, but it is a very simple button press. I'm just saying, beware of the non-thread-safety of the Tk module. The general advice to absolutely avoid the possible problem, is shown in PerlTk on a thread....... the copy-on-write thread action combined with the non-thread safety of Tk, means you need to follow alot of restrictions for foolproof operation of your Tk-threaded program. However, threads aside, if you just want to execute something and move on, you can fork it off with a piped open, IPC::Open3, etc. Then use Tk::fileevent, or i used a timer in the first code block, to read the results as they come back in.
and reading with a fileevent
| [reply] [d/l] [select] |
|
Re: Executing functions in Perl::Tk
by doug (Pilgrim) on Feb 24, 2010 at 19:31 UTC | |
This is more of a perception problem than a technical one. If you are more interested in hiding the issue than actually fixing it, launch the report generator in the background (system() with an & at the end) and have it write its output to a file. Then fire up a message box that says "report generation in progress" and has no clickable buttons. Next schedule a subroutine to run every 0.5 seconds to see if the report generation is done, and once it is, destroy the message box and slurp in the generated report. Although as ugly as sin, this doesn't require any fancy threading, and doesn't block the application from redrawing the windows. And that annoying message box (and you know it will annoy your users) will keep them busy/pacified for the 5 seconds or so you said that are needed to generate the report. You can put a countdown or progress bar on that message if you want to get fancy and can really estimate when it will be done. - doug | [reply] |