wxruby users - Oct 2007 - Crash when using item data with a CheckListBox

Hi,

The following code works as expected with a list box.

require "wx"

class HelloWorld < Wx::App
  def on_init
    helloframe = Wx::Frame.new(nil, "Hello World")

    choices = ["one", "two", "three",
"four", "five"]
    data = ["data1", "data2", "data3",
"data4", "data5"]
    lb = Wx::ListBox.new(helloframe)
#    lb = Wx::CheckListBox.new(helloframe)
    0.upto(4) { |i| lb.append(choices[i], data[i]) }

    evt_listbox lb do |event|
      puts lb.get_item_data(event.index)
    end

    helloframe.show
  end
end

HelloWorld.new.main_loop


When an item is selected, the corresponding data is ouput.
If the list box is replaced by a check list box, the application
crashes immediately.

Cheers.

Chauk-Mean.

Chauk-Mean P wrote:
> Hi,
>
> The following code works as expected with a list box.
Could you let us know what platform you''re on? Apart from an assert 
failure on exit with the debug build, it seems to work fine on GTK.

thanks
alex

Alex,

As you answer questions only from the wxruby-users, I''m wondering if
you still receive mails from the wxruby-development ML.

Anyway, I would appreciate any feedback on the crash I have with CheckListBox.
I''m running on Windows.

Cheers.

Chauk-Mean.

---------- Forwarded message ----------
From: Chauk-Mean P <chauk.mean at gmail.com>
Date: 16 oct. 2007 09:44
Subject: Re: [wxruby-development] Crash when using item data with a CheckListBox
To: wxruby-development at rubyforge.org


Alex,
> > 2007/10/9, Alex Fenton <alex at pressure.to>:
> > > Chauk-Mean P wrote:
> > > > Hi,
> > > >
> > > > The following code works as expected with a list box.
> > >
> > > Could you let us know what platform you''re on? Apart
from an assert
> > > failure on exit with the debug build, it seems to work fine on
GTK.
> >
> > I''m running on Windows 2000.
>
> Have you been able to reproduce the problem on Windows ?
Any feedback ?
Have you received my previous posts ?

Cheers,

Chauk-Mean.

Hey Chauk

Chauk-Mean P wrote:
> As you answer questions only from the wxruby-users, I''m wondering
if
> you still receive mails from the wxruby-development ML.
>   
I definitely follow and respond on both. But I hadn''t seen anything 
further on this thread after your original message and my first reply on 
the list - no follow-up. There''s nothing showing up in the archives:

http://rubyforge.org/pipermail/wxruby-development/2007-October/thread.html

I''m wondering if there is a problem with the wx-dev m.l. Your message 
seems to have been dropped, and I sent a message about two-three hours 
ago (about 1.9.2 and OpenGL) and it hasn''t shown
up.
> Anyway, I would appreciate any feedback on the crash I have with
CheckListBox.
> I''m running on Windows.
>   
Now I know you''re on Windows, I''ll look into it and see if I
can
reproduce the issue with XP.

Sorry for any confusion with the m.l.

cheers
alex

Alex,

2007/10/16, Alex Fenton <alex at pressure.to>:
> Hey Chauk
>
> Chauk-Mean P wrote:
> > As you answer questions only from the wxruby-users, I''m
wondering if
> > you still receive mails from the wxruby-development ML.
> >
> I definitely follow and respond on both. But I hadn''t seen
anything
> further on this thread after your original message and my first reply on
> the list - no follow-up. There''s nothing showing up in the
archives:
>
> http://rubyforge.org/pipermail/wxruby-development/2007-October/thread.html
>
> I''m wondering if there is a problem with the wx-dev m.l.
The wx-users m.l. archive from rubyforge doesn''t seem to work neither.
( http://rubyforge.org/pipermail/wxruby-users/2007-October/thread.html ).
Only old messages are shown.

Fortunately, I receive all mails on my mail account.
> > Anyway, I would appreciate any feedback on the crash I have with
CheckListBox.
> > I''m running on Windows.
> >
> Now I know you''re on Windows, I''ll look into it and see
if I can
> reproduce the issue with XP.
Great ! Note that I''m running Windows 2000 SP4. It may help you.

Cheers.

Chauk-Mean.

Hi Chauk-Mean

Chauk-Mean P wrote:
> The following code works as expected with a list box.
> When an item is selected, the corresponding data is ouput.
> If the list box is replaced by a check list box, the application
> crashes immediately.
Seems it''s down to this statement in the wxWidgets CheckListBox 
documentation:

" Please note that wxCheckListBox uses client data in its 
implementation, and therefore this is not available to the application."

When I tried out your example with a DEBUG build on Windows, it gives an 
assertion failure saying that item data can''t be used with 
wxCheckListBox. I''d guess that in the RELEASE builds we distribute it 
blithely carries on and tries to convert a wxWidgets internal structure 
into a Ruby object, which crashes.

So, sorry, I don''t think we can fix this as it''s a Wx
limitation.

I''ve updated the wrapper so that it raises a sensible ruby Exception if
someone tries to set item data on a CheckListBox, rather than crashing.

Thanks for the report, PS - and also spotting the prob with the -users 
m.l. archive.

cheers
alex

Alex,

2007/10/18, Alex Fenton <alex at pressure.to>:
> Hi Chauk-Mean
>
> Chauk-Mean P wrote:
> > The following code works as expected with a list box.
> > When an item is selected, the corresponding data is ouput.
> > If the list box is replaced by a check list box, the application
> > crashes immediately.
> ...
> " Please note that wxCheckListBox uses client data in its
> implementation, and therefore this is not available to the
application."
> ...
> So, sorry, I don''t think we can fix this as it''s a Wx
limitation.
Thanks for your investigation.

It''s a shame that an implementation issue in wxWidgets has such an
impact on the API / usage side.

I''m just wondering if you make / have made improvement requests to the
wxWidgets team based on your work on wxRuby ?
I can probably make such a request but you may have more influence
given your position as a core developer of wxRuby.

Cheers.

Chauk-Mean.

PS :
I''m very pleased by your openness and more generally the openness of
the development team.

Chauk-Mean P wrote:
> It''s a shame that an implementation issue in wxWidgets has such an
> impact on the API / usage side.
>
> I''m just wondering if you make / have made improvement requests to
the
> wxWidgets team based on your work on wxRuby ?
> I can probably make such a request but you may have more influence
> given your position as a core developer of wxRuby.
>   
I don''t know about that, but the core developers of WxWidgets and 
wxPython have been very helpful on the couple of occasions I''ve asked 
for advice and support.

Given that they seem talented developers, I guess it''s just hard to fix
this shortcoming with CheckListBox which I think is an emulated widget 
on MSW.

It''s probably easier just to use a Ruby array to hold the item data - 
this is how we used to do it in the "olden days" before we fixed the 
memory bugs with item_data methods around version 0.0.38. A subclass 
just needs to dupe the methods that insert and delete items, and 
item_data, to keep the array in sync.

I''d be open to a patch that does this for the core Wx::CheckListBox 
class to overcome this limitation.

cheers
alex

2007/10/22, Alex Fenton <alex at pressure.to>:
> Chauk-Mean P wrote:
> > It''s a shame that an implementation issue in wxWidgets has
such an
> > impact on the API / usage side.
> >
> It''s probably easier just to use a Ruby array to hold the item
data -
> this is how we used to do it in the "olden days" before we fixed
the
> memory bugs with item_data methods around version 0.0.38. A subclass
> just needs to dupe the methods that insert and delete items, and
> item_data, to keep the array in sync.
>
> I''d be open to a patch that does this for the core
Wx::CheckListBox
> class to overcome this limitation.
I''m gonna do it.

Cheers.

Chauk-Mean.

Hi,

2007/10/22, Chauk-Mean P <chauk.mean at
gmail.com>:
> 2007/10/22, Alex Fenton <alex at pressure.to>:
> >
> > I''d be open to a patch that does this for the core
Wx::CheckListBox
> > class to overcome this limitation.
>
> I''m gonna do it.
Here is the checklistbox.rb patch (for wxRuby 1.9.2) with a sample
which makes use of each method. Note that I also add a checked_items
method which returns the index of all checked items. I find it useful
and it is similar as the selections method for selected items.

Cheers.

Chauk-Mean.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: checklistbox.rb
Url:
http://rubyforge.org/pipermail/wxruby-development/attachments/20071023/1c07326c/attachment.pl
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: checklistbox_sample.rb
Url:
http://rubyforge.org/pipermail/wxruby-development/attachments/20071023/1c07326c/attachment-0001.pl

Chauk-Mean P wrote:
> Here is the checklistbox.rb patch (for wxRuby 1.9.2) with a sample
> which makes use of each method. Note that I also add a checked_items
> method which returns the index of all checked items. 
Great work, thanks. I just checked this in with some very minor tweaks:

* adjusted the instance variable name to reduce chance of collisions 
with user-defined names
* cosmetic alterations to avoid a warning and make similar to the rest 
of the ruby part of the API (which, for better or worse, is pretty much 
my style ;))

I''ll update the docs now. Thanks again
alex

Alex,

2007/10/23, Alex Fenton <alex at pressure.to>:
> Chauk-Mean P wrote:
> > Here is the checklistbox.rb patch (for wxRuby 1.9.2) with a sample
> > which makes use of each method. Note that I also add a checked_items
> > method which returns the index of all checked items.
> Great work, thanks.
You''re welcome.

But I have a problem when a CheckListBox is used in a XRC file.

clb = find_window_by_id(Wx::xrcid(''OPTIONS'')
#clb.clear

If one of the methods that have been redefined (e.g. clear) is called :
- a warning is output (instance variable @__wx_item_data not
initialized) on the console
- the called method fails due to the problem above

It seems that the initializer is not properly called when XRC is used.

Chauk-Mean.

Chauk-Mean P wrote:
> But I have a problem when a CheckListBox is used in a XRC file.
>
> clb = find_window_by_id(Wx::xrcid(''OPTIONS'')
> #clb.clear
>
> If one of the methods that have been redefined (e.g. clear) is called :
> - a warning is output (instance variable @__wx_item_data not
> initialized) on the console
> - the called method fails due to the problem above
>
> It seems that the initializer is not properly called when XRC is used.
>   
Ugh, good spot. This is going to be to be a problem with a few classes 
that use Ruby instance variables to handle memory management or other 
probs (Wx::Grid springs to mind).

The main C implementation of find_window_by_id and similar methods is in 
swig/shared/get_ruby_window.i. This basically wraps a C++ object using 
the SWIG API and some custom wxRuby code, all of which bypasses Ruby''s 
standard initializers.

The only solution I can think of is to have any method that relies on a 
instance variable is do a @_foo ||= [] or similar at the start, instead 
of relying on the initializer to set up the variable. A bit ugly, really

alex

2007/10/24, Alex Fenton <alex at pressure.to>:
>
> The only solution I can think of is to have any method that relies on a
> instance variable is do a @_foo ||= [] or similar at the start, instead
> of relying on the initializer to set up the variable. A bit ugly, really
>
Defining a private read accessor that does the initialization only
once can make things a little better,

In the CheckListBox case (not yet tested) :

class Wx::CheckListBox
  # no need for initialize redefinition anymore

  def __wx_item_data
    @__wx_item_data ||= []
  end

  private :__wx_item_data

  def clear
    super
    __wx_item_data.clear
  end

  # other methods

end

Chauk-Mean.

Chauk-Mean P wrote:
> 2007/10/24, Alex Fenton <alex at pressure.to>:
>   
>> The only solution I can think of is to have any method that relies on a
>> instance variable is do a @_foo ||= [] or similar at the start, instead
>> of relying on the initializer to set up the variable. A bit ugly,
really
>>
>>     
> Defining a private read accessor that does the initialization only
> once can make things a little better,
>   
That''s a bit less ugly. I just checked in a revised version that should
now work with XRC. Let me know if any probs

cheers
alex

Alex,

2007/10/24, Alex Fenton <alex at pressure.to>:
> Chauk-Mean P wrote:
> >>
> > Defining a private read accessor that does the initialization only
> > once can make things a little better,
> >
> That''s a bit less ugly. I just checked in a revised version that
should
> now work with XRC. Let me know if any probs
This works but I find strange that you change the implementation of append :

  def append(item, data = nil)
    super(item)
    __wx_item_data[count - 1] = data
  end

The following works as well, is more natural and is more efficient (no
call to count, no addition) :

  def append(item, data = nil)
    super(item)
    __wx_item_data << data
  end

Can you just fix this.
Thanks in advance.

Cheers.

Chauk-Mean.

Chauk-Mean P wrote:
> This works but I find strange that you change the implementation of append
:
>
>   def append(item, data = nil)
>     super(item)
>     __wx_item_data[count - 1] = data
>   end
>   
If the control was loaded from XRC, it may already have items inserted 
into it, but the item data array would be empty. So appending to the 
array would insert at position 0, not n, the correct last position.

alex

2007/10/25, Alex Fenton <alex at pressure.to>:
> Chauk-Mean P wrote:
> > This works but I find strange that you change the implementation of
append :
> >
> >   def append(item, data = nil)
> >     super(item)
> >     __wx_item_data[count - 1] = data
> >   end
> >
> If the control was loaded from XRC, it may already have items inserted
> into it, but the item data array would be empty. So appending to the
> array would insert at position 0, not n, the correct last position.
>
I see. You''re right.

Cheers.

Chauk-Mean.