wxruby users - Jun 2009 - Refreshing Window

If a long (relatively) operation takes place after dismissing a dialog,
the underlying window is in an indeterminate state until the operation
is complete. It would be good to be able to periodically display a
status update - or let the user know what''s happening. To do this, I
need some way to force the system to go back through the event loop so
that the screen gets properly updated.

I''m probably a bit dense here, but I don''t see how this could
be done.
I''m sure some of you have already encountered this and figured out how
to do it.

How can this be done? Enquiring minds would love to know.

---Michael
-- 
Posted via http://www.ruby-forum.com/.

I posted with a similar problem.  The solution was to use evt_idle. 
Just set it like this:

# run dialog box
# user replies
evt_idle do
    # do whatever it is you want to do, including
    # changing a progress bar, label, or whatever.
end

Instead of

# run dialog box
# user replies
# do whatever...

The evt_idle just doesn''t allow the process to run until nothing is 
happening.

However, please note that the window will still be frozen, but whatever 
changes you make will be applied.

I''ll follow this to find out if it''s possible to keep it from
being
frozen altogether :)

Cheers
-- 
Posted via http://www.ruby-forum.com/.

On Sat, 6 Jun 2009 23:45:38 +0200
Jonah Dahlquist <lists at ruby-forum.com> wrote:
> I posted with a similar problem.  The solution was to use evt_idle. 
> Just set it like this:
> 
> # run dialog box
> # user replies
> evt_idle do
>     # do whatever it is you want to do, including
>     # changing a progress bar, label, or whatever.
> end
> 
> Instead of
> 
> # run dialog box
> # user replies
> # do whatever...
> 
> The evt_idle just doesn''t allow the process to run until nothing
is
> happening.
> 
> However, please note that the window will still be frozen, but
> whatever changes you make will be applied.
> 
> I''ll follow this to find out if it''s possible to keep it
from being
> frozen altogether :)
> 
> Cheers
yes I have solved it the same way. 

But I was wondering if it were possible to make a
''evt_idle_once''
function. That only run once and the gets removed from the event que. 
It seems a little inefficient, that the block is call every time there
is some idle time, even if it is only needed to run it once.

Great reply, thanks!  As to the evt_idle_once, all you have to do is 
this:

evt_idle do
    evt_idle do end
    # your code
end

That empties the evt_idle function as soon as it is called.
-- 
Posted via http://www.ruby-forum.com/.

Mario Steele wrote:
> It should also be noted, that with this setup, is optimal for Ruby 1.8
> series.  The reason for this, and the reason for the Timer in the first
> place for this method, is that in Ruby 1.8 series, Threads are green
> threads.  Meaning that they are software layer threads.  They are 
> entirely
> managed by the Ruby interpreter itself, and never goes out to the 
> Operating
> System itself to control the thread.  This is where you have quite a few
> problems with Wx::Ruby, and Ruby itself.  Now the reason why it''s 
> limited to
> the Ruby 1.8 Series, and earlier actually, is cause the Ruby 1.9 series, 
> to
> be dubbed 2.0, uses Operating System Threads.  And as Alex has explained 
> to
> me on this subject, You can create threads in Ruby 1.9, and Wx::Ruby, 
> and
> things will work, as long as you keep any updates that you do the GUI in 
> the
> Main Thread.  So if you need to update a progress bar, or display some 
> text
> in a window, it''s best to do that in the main thread, and not the 
> sub-thread
> that you create for the processing of the file.
Perhaps it''s a problem with the OS X implementation (1.9.1p376), but so
far I''m not getting any better results with threads in Ruby 1.9... I 
start a thread from a Wx::App on_init like follows:

    Thread.new do
      loop do
        puts "1: #{Time.new}"
        puts "1b: #{Time.new}"
        puts "1c: #{Time.new}"
        puts "1d: #{Time.new}"
        ...

And once started, the output looks like:

1: 2010-02-18 20:18:47 +0000
1b: 2010-02-18 20:18:48 +0000
1c: 2010-02-18 20:18:51 +0000
1d: 2010-02-18 20:18:55 +0000

This is quite amazingly slow - I guess the call to Time.new and 
.to_s/puts blocks and the thread sleeps, but up to 4 seconds between 
simple expressions is a lot!

Using the Timer hack to cooperatively schedule the threads seems to 
work, just like in Ruby 1.8.

Ois?n
-- 
Posted via http://www.ruby-forum.com/.