Question about GUI processing order

Desktop wxRuby
1

I am developing a GUI with WxRuby (wxruby-1.9.1-i386-mswin32,
ruby-1.8.6).
In one of my button event handlers I do the following in this order:

set the value of a TextCtrl,

show a button (which was hidden),

hide the button that was caused this event

play some sounds (using Sound.play)

What I observe is that all these things happen, but not in the order I
specified. Hiding the button occurs before the sounds are played, but
setting the value of the TextCtrl, and showing the hidden button does
not
happen until after the sounds are finished. It is important the first
three
things happen before the sounds are played.

Any ideas about what’s going on or how I can fix it?

Thanks,

Eric R.

2

Calling update fixed it. Thanks.

I am using 1.9.1 and Sound.play is working…

Eric

3

Eric R. wrote:

play some sounds (using Sound.play)

What I observe is that all these things happen, but not in the order I
specified. Hiding the button occurs before the sounds are played, but
setting the value of the TextCtrl, and showing the hidden button does
not happen until after the sounds are finished. It is important the
first three things happen before the sounds are played.

It may well be because visual updates to Windows are not necessarily
done immediately, but in the next event loop. You should be able to
force the immediate repainting of a window and its children by calling

window.refresh # mark the whole window as needing repainting
window.update # specify that areas need repainting should be dealt with
now

Then call Sound.play. If this doesn’t help, perhaps shows us some code.
See http://wxruby.rubyforge.org/doc/window.html#Window_refresh

PS - are you sure you’re using 1.9.1 - I think Sound.play is only
supported in SVN HEAD?!

alex

4

Eric R. wrote:

Calling update fixed it. Thanks.

Cool.

I am using 1.9.1 and Sound.play is working…

That’s very weird. I can’t find any reference to Sound or play in the
1.9.1 sources.

Anyway, be aware that in the upcoming 1.9.2 release, the class method
‘play’ is called ‘play_sound’, and the instance method is ‘play’.

It’s not ideal but the only way I could find to work around a SWIG bug.

alex

5

Eric R. wrote:

The Sound I’m using is not part of WxRuby. It’s in the win32-sound gem.

OK, now I’m less bemused.

If 1.9.2 will include a platform independent Sound, that’s great. But will
there be a conflict with win32-sound? Or at least a source of confusion?

Yes, it’s platform independent, and allows synchronous and async playing
of wav files.

There shouldn’t be a conflict because wxRuby’s Sound will live within
the Wx:: namespace. Eg Wx::Sound.new(‘foo.wav’).play

The only possible problem would be if you do “include Wx” at the start
of a script to avoid having to type the Wx:: prefix everywhere. But this
kind of namespace stomping isn’t recommended for larger scripts which
use multiple libraries, for this reason.

alex

6

The Sound I’m using is not part of WxRuby. It’s in the win32-sound gem.
See
http://rubyonwindows.blogspot.com/2007/05/adding-sound-to-your-ruby-apps.htm
l

If 1.9.2 will include a platform independent Sound, that’s great. But
will
there be a conflict with win32-sound? Or at least a source of
confusion?

Eric