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 Rubin _______________________________________________ wxruby-users mailing list wxruby-users@rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Eric Rubin wrote:> > 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. >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
Calling update fixed it. Thanks. I am using 1.9.1 and Sound.play is working... Eric -----Original Message----- From: wxruby-users-bounces at rubyforge.org [mailto:wxruby-users-bounces at rubyforge.org] On Behalf Of Alex Fenton Sent: Tuesday, October 16, 2007 12:52 PM To: General discussion of wxRuby Subject: Re: [wxruby-users] Question about GUI processing order Eric Rubin wrote:> > 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. >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 _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Eric Rubin 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
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 -----Original Message----- From: wxruby-users-bounces at rubyforge.org [mailto:wxruby-users-bounces at rubyforge.org] On Behalf Of Alex Fenton Sent: Tuesday, October 16, 2007 2:05 PM To: General discussion of wxRuby Subject: Re: [wxruby-users] Question about GUI processing order Eric Rubin 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 _______________________________________________ wxruby-users mailing list wxruby-users at rubyforge.org http://rubyforge.org/mailman/listinfo/wxruby-users
Eric Rubin 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