Beefy Boxes and Bandwidth Generously Provided by pair Networks
Welcome to the Monastery
 
PerlMonks  

Perl/Tk window contents disappear when obscured then revealed

by Another Ed (Sexton)
on Jan 21, 2013 at 15:06 UTC ( #1014459=perlquestion: print w/ replies, xml ) Need Help??
Another Ed has asked for the wisdom of the Perl Monks concerning the following question:

I am having problems with Perl/Tk windows. Certain ones have the feature that if you obscure them with another window - wholly or partially - then reveal them again, the window contents are missing - wholly or partially again. I have found this with both mySplashScreen and Message windows. How can I avoid this happening, or is this a "feature" of these objects? Sample code I have been using:
use Tk; require Tk::mySplashScreen; use strict; use warnings; my $s = mySplashScreen -> new ( -image => '', -text => 'testing, one, two, three...' ); for my $n (1 .. 10) { print "$n\n"; sleep 1; } $s -> destroy;
And:
use Tk; use strict; use warnings; my $mw = MainWindow -> new; my $m = $mw -> Message (-text => "testing, one, two, three...") -> pac +k; $m -> update; for my $n (1 .. 10) { print "$n\n"; sleep 1; } $m -> destroy; print "Done\n";
If this feature is unavoidable for these objects, is there an alternative type I can use? All I am trying to do is display a message window that remains on the screen while a called application (a scanner program) runs. I cannot believe how difficult it is to achieve something so basic. I have tried Google and turned up nothing for this.

Comment on Perl/Tk window contents disappear when obscured then revealed
Select or Download Code
Re: Perl/Tk window contents disappear when obscured then revealed
by choroba (Abbot) on Jan 21, 2013 at 15:18 UTC
    I cannot find Tk::mySplashScreen in Tk.

    For the second example, just move the update line inside the loop. You have to update the window to make it redraw itself.

    لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

      Hi, thanks for your reply. I don't think I made myself clear: the loops in the example code I posted are not there for any purpose other than for the Perl script to do something while the message window is displayed. In the real code, there would be a Perl 'system' call to a scanner program, requiring user interaction, at that point. Therefore there is no loop in the real code.

      I must confess that, even if I had a loop in the real code, I wouldn't feel comfortable with putting in a forced "refresh" every time round it: surely there's a less crude way of not losing the contents of a window?

        Perhaps you need to run your system command as a background process? The problem is that when you run a system command that seizes control of the current process, the Tk event loop doesn't get executed, so no window updates occur. If you call external programs in their own process, it allows the Tk events some processing time.

        See below: (Windows example, adjust as necessary to call background processes in your OS)

        use strict; use warnings; use Tk; my $mw = MainWindow->new; my $m = $mw->Message(-text => "testing, one, two, three...")->pack; $mw->update; system("start notepad.exe"); MainLoop;

        For your sleep example? Well, if you don't call your event loop periodically, don't be surprised if your events don't get processed...

Re: Perl/Tk window contents disappear when obscured then revealed
by BrowserUk (Pope) on Jan 21, 2013 at 16:18 UTC

    Tk will not respond to changes -- caused by the program or external factors like screen changes -- unless you enter MainLoop.

    See the POD examples for the details.


    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
    With the rise and rise of
      In fact, $m->update works as entering the main loop. And even entering the main loop does not magically remove any blocking:
      #!/usr/bin/perl use warnings; use strict; use Tk; my $mw = MainWindow -> new; my $m = $mw -> Message (-text => "testing, one, two, three...") -> pa +ck; $mw->Button(-text => 'Go', -command => \&fire)->pack; MainLoop(); sub fire { for my $n (1 .. 10) { print "$n\n"; sleep 1; } $m -> destroy; print "Done\n"; }
      لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ

        Update only works once; MainLoop effectively call update again whenever it is required.

        Of course, if you sleep for 10 seconds in a callback routine, control will not return to MainLoop for 10 seconds and no updates will be handled during that time.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        Hi choroba, I tried your script, and unfortunately it gave the same unwanted effect as my example: the contents of the dialog had disappeared after the window was obscured then revealed while the 'for' loop was running. Ed

      Hi BrowserUk, thanks for your reply. I was under the impression that entering MainLoop put Perl/Tk into a state of waiting for and handling user interaction, such as clicking a button on a dialog. This is not what I want to do at this point in my program: I want Perl to display a message (one which doesn't disappear), invoke an external program (the scanner program), then carry on processing (without user interaction) once the external program has been closed by the user. Sounds a simple sequence of events, but I'm beginning to think that Perl can't handle it.

      Do feel free to correct me if you still think MainLoop is appropriate here. Any pointers to specific documentation other than "RTFM" would be appreciated.

        "carry on processing" is not an event. Start the program in the background, make its finish an event.
        لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
        Do feel free to correct me if you still think MainLoop is appropriate here.

        The nature of GUI's is that whenever a window (or part thereof) is uncovered; or has its size changed, you have to re-draw the contents of that window.

        To achieve that you can call $->update() within long running loops; but that will often mean that updates are forced each time around the loop when they are not needed -- ie. you chew CPU for no reason -- or you can enter the event loop (MainLoop;) which will monitor the event queue and call update() only when it is required; along with servicing any and all other events as they occur.

        If you have a piece of code to run that is going to take more than say 1/10th of a second, then you have three choices:

        1. Just run the code and accept that the GUI will 'freeze' for the duration.

          This is what you have now. It's not nice or professional.

        2. Break the processing into small bits that take less than 1/10th of a second and arrange to call update() (Or better: DoOneEvent() or DoEvents()) between those small chunks.

          In practice, putting a call to DoEvents() into a convenient place in your processing loop works well enough provided that you have a loop and its frequency is neither too fast nor too slow.

          Not all long running processing involves convenient user-code loops. Waiting for an external command is one such situation.

          And even when it does; if the loop is very tight; constantly calling out to DoEvents() can substantially slow down the processing; doubling or trebling the time it takes.

          Conversely, if the loop itself takes long than 1/10th of a second to iterate, the GUI can become sluggish to respond to user input.

          This can be finely tuned by only calling DoEvent() every 5th, or 50th or 500th iteration for the fast loop; or calling it at multiple places for the slow loop; but it requires trial and error to strike the optimal balance between GUI responsiveness and processing throughput.

          But the big problem is that when you've achieve that fine balance on your development machine and move it to a different machine; the balance is lost because that machine has a faster or slower CPU; memory; disk; or a higher background workload; or any of a dozen other differences that screw up your hard one balancing act.

        3. Put the long running processing into a background thread or process.

          This is best of all, because the OS scheduler takes care of balancing the needs of the GUI responsiveness with the CPU requirements of the processing.

          Whether a background thread or process is the best solution for your application very much depends upon what that application is.

        What is this program that you are running in the background? Does it produce output that you need in your GUI application? Does it produce a file that you then need to read?

        If you supply more details; we might be able to recommend a better way of tackling the problem.


        With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
        Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
        "Science is about questioning the status quo. Questioning authority".
        In the absence of evidence, opinion is indistinguishable from prejudice.
        This can be finely tuned by only calling for the duration.
Re: Perl/Tk window contents disappear when obscured then revealed
by BrowserUk (Pope) on Jan 21, 2013 at 16:50 UTC

    This may be close to what you are trying to do:

    use strict; use warnings; use Tk; my $mw = MainWindow -> new; my $m = $mw -> Message (-text => "testing, one, two, three...") -> pac +k; my $n = 0; $mw->repeat( 1000, sub{ $mw->destroy if ++$n == 10; print "$n\n"; } ); MainLoop; print "Done\n"; __END__ C:\test>\perl32\bin\perl junk91.pl 1 2 3 4 5 6 7 8 9 10 Done

    With the rise and rise of 'Social' network sites: 'Computers are making people easier to use everyday'
    Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
    "Science is about questioning the status quo. Questioning authority".
    In the absence of evidence, opinion is indistinguishable from prejudice.
Re: Perl/Tk window contents disappear when obscured then revealed
by Anonymous Monk on Jan 22, 2013 at 14:24 UTC
      Yep, this works on Linux:
      #!/usr/bin/perl use warnings; use strict; use Tk; use Proc::Background; my $mw = MainWindow->new; my $msg = $mw->Label(-text => 'Press the button once ready.')->pack +; my $button = $mw->Button(-text => 'Start', -command => \&run, )->pack; MainLoop(); sub run { my $proc = Proc::Background->new('kate'); # an editor $mw->update while $proc->alive; $mw->Label(-text => 'Finished.')->pack; $button->destroy; }
      لսႽ ᥲᥒ⚪⟊Ⴙᘓᖇ Ꮅᘓᖇ⎱ Ⴙᥲ𝇋ƙᘓᖇ
        You could even do timers
        our @procs; $mw->repeat( 100, \&diddleProcs ); MainLoop; sub run { ... push @procs, $proc; } sub diddleProcs { my @goners; my @alive; for ( @procs ){ if( $_->alive ){ push @alive, $_; } else { push @goners, $_; } } @procs = @alive; PackGoners(\@goners); }

Log In?
Username:
Password:

What's my password?
Create A New User
Node Status?
node history
Node Type: perlquestion [id://1014459]
Approved by MidLifeXis
Front-paged by MidLifeXis
help
Chatterbox?
and the web crawler heard nothing...

How do I use this? | Other CB clients
Other Users?
Others avoiding work at the Monastery: (6)
As of 2014-11-22 10:24 GMT
Sections?
Information?
Find Nodes?
Leftovers?
    Voting Booth?

    My preferred Perl binaries come from:














    Results (121 votes), past polls