I’m working on enabling/disabling controls, and I keep getting
exceptions like the following:
mysource.rb:262:in enable': Expected argument 1 of type bool, but got NilClass nil (TypeError) in SWIG method 'Enable' from mysource.rb:262 from C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe s/app.rb:16:incall’
from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in process_event' from C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe s/app.rb:16:inon_run’
from
C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe
s/app.rb:16:in main_loop' from C:/Ruby187/lib/ruby/gems/1.8/gems/wxruby-2.0.1-x86-mingw32/lib/wx/classe s/app.rb:16:inrun’
from app.rb:188
Is there an (easy) way to help WxRuby follow Ruby’s notion of truth,
i.e. everything but +nil+ and +false+ are true?
The current best workaround I have is
enable(… ? true : false)
but that’s clunky, and I obviously keep forgetting to use it. 
Thanks!
Ryan H.
L-3 Communications / Communication Systems West
[email protected]
Hi Ryan
[list generally - I’ve had problems receiving wxruby-users posts in the
past month - apologies for any missed discussions]
On 02/07/2011 00:10, [email protected] wrote:
I’m working on enabling/disabling controls, and I keep getting
exceptions like the following:
mysource.rb:262:in `enable’: Expected argument 1 of type bool, but got
NilClass nil (TypeError)
in SWIG method ‘Enable’
from mysource.rb:262
from
These exceptions come from SWIG’s default way of wrapping C/C++ methods
that require a C boolean type.
Is there an (easy) way to help WxRuby follow Ruby’s notion of truth,
i.e. everything but +nil+ and +false+ are true?
The current best workaround I have is
enable(… ? true : false)
but that’s clunky, and I obviously keep forgetting to use it. 
Globally, it could be changed by altering the standard way that wxRuby
SWIG translates methods that require a boolean. It is a pretty simple
%typemap statement but obviously requires the whole SWIG+compiler
set-up. However it’s a change I’d be open to adding for future versions,
as I think SWIG’s approach is sometimes too class-strict for Ruby style.
For the time being, the only way would be either to add your workaround
to a subclass of the control, so that its enable method looked like
super(input ? true : false). Or you could do some reflection and find
methods called ‘enable’ in all wxRuby classes at start-up and redefine
them. But from experience (at least with Ruby 1.8) it does take a little
time to cycle through all the 200+ classes.
best
alex
Alex:
Thanks for the RubyForge tracker pointer. I’ll add this to the list.
FYI, I just squashed a related bug. I was returning +nil+ when a
drag-drop operation failed, and it would crash my application. I just
added the
? true : false
trick on my return value, and the crash is gone. I assume the SWIG
solution would handle this case, too.
Thanks!
I’m already a bit over-budget; I won’t have time to set up the full
environment now. Is there a bug-tracking system I can enter this as an
enhancement request?
http://rubyforge.org/tracker/?atid=221&group_id=35&func=browse
cheers
alex
On 05/07/11 22:18, [email protected] wrote:
FYI, I just squashed a related bug. I was returning +nil+ when a
drag-drop operation failed, and it would crash my application. I just
added the
? true : false
trick on my return value, and the crash is gone. I assume the SWIG
solution would handle this case, too.
Thanks for the info. Standard SWIG covers straightforward cases (e.g.
Ruby arguments to C++ methods). Some stuff like drag-drop where C++ code
calls Ruby then back to C++ is more tricky and there may be unsafe
conversions. So it would be great if you could add a couple of details
in a bug report.
alex
On Tue, Jul 5, 2011 at 5:18 PM, [email protected] wrote:
trick on my return value, and the crash is gone. I assume the SWIG
Subject: Re: [wxruby-users] Enable input and Ruby true/false semantics
I’m working on enabling/disabling controls, and I keep getting
methods
but that’s clunky, and I obviously keep forgetting to use it. 
I’m already a bit over-budget; I won’t have time to set up the full
little
wxruby-users mailing list
[email protected]
http://rubyforge.org/mailman/listinfo/wxruby-users
I realize I’m a bit late and not really solving the core issue, but: one
of
the common ways to approach forcing a boolean datatype, in the rails
world
at least, is to double up your boolean not operators: !!.
It’s a
little weird looking at first but gets the same results as (
?
true : false) with less typing.
–Stephen
