wxruby users - Jan 2008 - No joy from Wx::App.dispatch, Wx::App.yield...

OK, back with another iteration of the same problem...  I updated my
game demo, but the Close button failed to respond when (and only when)
there were too many objects onscreen.  The drawing loop is probably
lasting longer than my drawing timer interval.  I was able to
reproduce the problem in my (probably familiar by now) test script
just by boosting the number of lines drawn per frame.

After each frame, I tried Wx::App.dispatch, Wx::App.dispatch while
Wx::App.pending, and Wx::App.yield, all without effect.  The
(commented out) statements are in the code below.

I''m running Ruby 1.8.6 on Windows with wxRuby 1.9.2 (1.9.3 and 1.9.4
both give me errors).

If wxRuby is busy drawing when the close button is clicked, is the
window close event getting lost altogether, or merely going unhandled?
 If it''s just going unhandled, how can I find it and process it?  Help
is, as always, most appreciated!

-Jay McGavren
http://jay.mcgavren.com/zyps


  require ''rubygems''
  require ''wx''

  class MyApp < Wx::App

    def on_init

      #Containing frame.
      frame = Wx::Frame.new(nil, :size => [300, 300])
      frame.show

      #Offscreen drawing buffer.
      buffer = Wx::Bitmap.new(300, 300)

      #Displays drawing.
      window = Wx::Window.new(frame, :size => [300, 300])
      window.evt_paint do |event|
        update_window(window, buffer)
      end

      #Initialize drawing loop counter.
      @i = 0

      #Animate periodically.
      timer_id = Wx::ID_HIGHEST + 1
      t = Wx::Timer.new(self, timer_id)
      evt_timer(timer_id) do
        animate(window, buffer)
        #No effect.
        #self.dispatch
        #No effect.
        #self.dispatch while self.pending
        #No effect.
        #self.yield
      end
      t.start(33)

    end

    def animate(window, buffer)
      green_pen = Wx::Pen.new(Wx::Colour.new(128, 255, 128), 3)
      black_pen = Wx::Pen.new(Wx::Colour.new(0, 0, 0), 0)
      buffer.draw do |surface|
        #Clear screen.
        surface.pen = black_pen
        surface.brush = Wx::BLACK_BRUSH
        surface.draw_rectangle(0, 0, 300, 300)
        #Draw lines.
        surface.pen = green_pen
        surface.pen.cap = Wx::CAP_ROUND
        30000.times do |j|
          x = @i + j
          surface.draw_line(x, 0, x+100, 100)
        end
      end
      #Update screen.
      update_window(window, buffer)
      @i += 1
      @i = 0 if @i > 300
    end

    def update_window(window, buffer)
      window.paint do |dc|
        #Copy the buffer to the viewable window.
        dc.draw_bitmap(buffer, 0, 0, false)
      end
    end

  end

  app = MyApp.new
  app.main_loop

Hello Jay,

To process an exit event, or rather a close event, utilize evt_close event
handler.  Also, what errors are you getting with 1.9.3/4?

On 1/19/08, Jay McGavren <jay at mcgavren.com>
wrote:
>
> OK, back with another iteration of the same problem...  I updated my
> game demo, but the Close button failed to respond when (and only when)
> there were too many objects onscreen.  The drawing loop is probably
> lasting longer than my drawing timer interval.  I was able to
> reproduce the problem in my (probably familiar by now) test script
> just by boosting the number of lines drawn per frame.
>
> After each frame, I tried Wx::App.dispatch, Wx::App.dispatch while
> Wx::App.pending, and Wx::App.yield, all without effect.  The
> (commented out) statements are in the code below.
>
> I''m running Ruby 1.8.6 on Windows with wxRuby 1.9.2 (1.9.3 and
1.9.4
> both give me errors).
>
> If wxRuby is busy drawing when the close button is clicked, is the
> window close event getting lost altogether, or merely going unhandled?
> If it''s just going unhandled, how can I find it and process it? 
Help
> is, as always, most appreciated!
>
> -Jay McGavren
> http://jay.mcgavren.com/zyps
>
>
>   require ''rubygems''
>   require ''wx''
>
>   class MyApp < Wx::App
>
>     def on_init
>
>       #Containing frame.
>       frame = Wx::Frame.new(nil, :size => [300, 300])
>       frame.show
>
>       #Offscreen drawing buffer.
>       buffer = Wx::Bitmap.new(300, 300)
>
>       #Displays drawing.
>       window = Wx::Window.new(frame, :size => [300, 300])
>       window.evt_paint do |event|
>         update_window(window, buffer)
>       end
>
>       #Initialize drawing loop counter.
>       @i = 0
>
>       #Animate periodically.
>       timer_id = Wx::ID_HIGHEST + 1
>       t = Wx::Timer.new(self, timer_id)
>       evt_timer(timer_id) do
>         animate(window, buffer)
>         #No effect.
>         #self.dispatch
>         #No effect.
>         #self.dispatch while self.pending
>         #No effect.
>         #self.yield
>       end
>       t.start(33)
>
>     end
>
>     def animate(window, buffer)
>       green_pen = Wx::Pen.new(Wx::Colour.new(128, 255, 128), 3)
>       black_pen = Wx::Pen.new(Wx::Colour.new(0, 0, 0), 0)
>       buffer.draw do |surface|
>         #Clear screen.
>         surface.pen = black_pen
>         surface.brush = Wx::BLACK_BRUSH
>         surface.draw_rectangle(0, 0, 300, 300)
>         #Draw lines.
>         surface.pen = green_pen
>         surface.pen.cap = Wx::CAP_ROUND
>         30000.times do |j|
>           x = @i + j
>           surface.draw_line(x, 0, x+100, 100)
>         end
>       end
>       #Update screen.
>       update_window(window, buffer)
>       @i += 1
>       @i = 0 if @i > 300
>     end
>
>     def update_window(window, buffer)
>       window.paint do |dc|
>         #Copy the buffer to the viewable window.
>         dc.draw_bitmap(buffer, 0, 0, false)
>       end
>     end
>
>   end
>
>   app = MyApp.new
>   app.main_loop
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>


-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
http://rubyforge.org/projects/vwmc/
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://rubyforge.org/pipermail/wxruby-users/attachments/20080119/3c7ea8b5/attachment.html

Mario Steele wrote:
> To process an exit event, or rather a close event, utilize
> evt_close event handler.
Well, look at that.  It had always worked on its own before, so I got
lazy.  But one line of code in on_init did it:

  frame.evt_close {|event| exit}
> Also, what errors are you getting with 1.9.3/4?
In a pop-up dialog:

The dynamic link library gdiplus.dll could not be found in the specified path
[long path omitted]

And on STDERR:

C:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.4-i386-mswin32/lib/wxruby2.so:
126: The specified module could not be found.   -
C:/ruby/lib/ruby/gems/1.8/gems/wxruby-1.9.4-i386-mswin32/lib/wxruby2.so
(LoadError)

This is on Windows 2000, BTW, I haven''t tried it on my XP setup (but
will if needed).

Many thanks for the help!

-Jay McGavren
http://jay.mcgavren.com/zyps

Jay McGavren wrote:
> In a pop-up dialog:
>
> The dynamic link library gdiplus.dll could not be found in the specified
path
> [long path omitted]
Thanks for the report. gdiplus.dll became a new dependency in 1.9.3 with 
the addition of the GraphicsContext classes for antialiased drawing.  We 
build and test on Win XP where it''s always available, and
didn''t realise
it wasn''t included in a default install of W2K. However it seems it can
downloaded and installed for free on 2000, and is often required by 
other apps.

Zyps looks a fascinating project, perhaps the most interesting I''ve
seen
in Ruby GUI programming. I''m keen to try it out; do let me know when 
there''s a release, or even when it''s runnable from SVN with
wxRuby.

alex

Alex Fenton wrote:
> Thanks for the report. gdiplus.dll became a new dependency
> in 1.9.3 with the addition of the GraphicsContext classes
> for antialiased drawing.  We build and test on Win XP where
> it''s always available, and didn''t realise it
wasn''t
> included in a default install of W2K. However it seems it
> can downloaded and installed for free on 2000, and is often
> required by other apps.
OK, I''ll look into getting it on Win2K.  1.9.4 did indeed run
out-of-the-box on my WinXP machine.
> Zyps looks a fascinating project, perhaps the most
> interesting I''ve seen in Ruby GUI programming. I''m keen
to
> try it out; do let me know when there''s a release, or even
> when it''s runnable from SVN with wxRuby.
Thanks for the kind words.  The library demo is runnable - just check
out HEAD (rev. 193), cd to the working copy, and say:

	$ set RUBYLIB=lib
	$ ruby bin/zyps_demo

...or the equivalents for your OS.  You''ll be gratified to know
I''m
getting far better framerates from wxRuby than I was with Ruby-Gnome2.

-Jay McGavren
http://jay.mcgavren.com/zyps

Jay McGavren wrote:
> The library demo is runnable - just check
> out HEAD (rev. 193), cd to the working copy, and say:
>
> 	$ set RUBYLIB=lib
> 	$ ruby bin/zyps_demo
>
>   
Great demo: fun, absorbing and a nice aesthetic too. If I get some time 
I might try to write a foxes/rabbits or simple genetics
simulator.
> ...or the equivalents for your OS.  You''ll be gratified to know
I''m
> getting far better framerates from wxRuby than I was with Ruby-Gnome2.
>   
That''s good to know.  Having a quick glance at the wx code helped turn 
up a bug - I realised the docs for Wx::Brush are cut off. A custom brush 
is created thus:

Wx::Brush.new(Wx::Colour.new(r, g, b), Wx::SOLID)

The second argument is the fill style - other options are things like 
Wx::CROSS_HATCH. Brushes that stipple Bitmaps can also be used to create 
textures.

http://www.wxwidgets.org/manuals/2.8/wx_wxbrush.html

The simplest constructor should be:

Wx::Brush.new(Wx::Colour(r, g, b)

But this form was missing - now added to SVN for the next release.

cheers
alex