Forum: wxRuby Enable input and Ruby true/false semantics

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:in `call'
        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:in `on_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:in `run'
        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 Hinton
L-3 Communications / Communication Systems West
ryan.w.hinton@L-3com.com

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, ryan.w.hinton@L-3com.com 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

> 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...

cheers
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

<expression> ? true : false

trick on my return value, and the crash is gone.  I assume the SWIG
solution would handle this case, too.

Thanks!

- Ryan

On 05/07/11 22:18, ryan.w.hinton@L-3com.com 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
>
> <expression>  ? 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, <ryan.w.hinton@l-3com.com> 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
> wxruby-users@rubyforge.org
> 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: !!<expression>. 
It's a
little weird looking at first but gets the same results as (<expression> 
?
true : false) with less typing.

--Stephen