wxruby development - Nov 2006 - TreeCtrl item_data

The attached fixes set_item_data, get_item_data and some other methods 
for the TreeCtrl so they work nicely with Ruby objects and GC.

In C++ Wx TreeCtrl item_data works differently from client_data in 
classes derived from ControlWithItems (eg Choice, ListCtrl). A 
one-to-one mapping of the way TreeCtrl works would mean that you would 
have to derive a class from TreeItemData, and instantiate one of this 
container class each time you wanted to associate a Ruby object with a 
tree item.

This seems very clumsy in Ruby, so I''ve used typemaps so that you can 
simply pass any Ruby object to a method that adds a tree item, or to 
set_item_data, and later call get_item_data to get the object back 
directly. The doc patch reflects this.

This means the whole TreeItemData class is not exposed at all in Ruby. I 
think this is the right way to go, but let me know if it sounds wrong 
and there''s situations where Ruby code might want this. This is similar
to, but not the same as the way wxPython and wxPerl deal with this.

I''m going to go back to the other ControlWithItems classes and add 
item_data support to them along the model of wxChoice. I think it is 
weird that methods that get data from an item in these classes are 
called get_CLIENT_data, and now the way they work will be consistent 
across TreeCtrl, Choice, ComboBox etc I plan to rename get_client_data 
to get_item_data. Again, shout if you think this is wrong.

cheers
alex
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: treectrl_itemdata.patch
Url:
http://rubyforge.org/pipermail/wxruby-development/attachments/20061112/eda2d167/attachment.pl

Alex Fenton wrote:
> The attached fixes set_item_data, get_item_data and some other methods 
> for the TreeCtrl so they work nicely with Ruby objects and GC.
>
> In C++ Wx TreeCtrl item_data works differently from client_data in 
> classes derived from ControlWithItems (eg Choice, ListCtrl). A 
> one-to-one mapping of the way TreeCtrl works would mean that you would 
> have to derive a class from TreeItemData, and instantiate one of this 
> container class each time you wanted to associate a Ruby object with a 
> tree item.
>
> This seems very clumsy in Ruby, so I''ve used typemaps so that you
can
> simply pass any Ruby object to a method that adds a tree item, or to 
> set_item_data, and later call get_item_data to get the object back 
> directly. The doc patch reflects this.
>
> This means the whole TreeItemData class is not exposed at all in Ruby. 
> I think this is the right way to go, but let me know if it sounds 
> wrong and there''s situations where Ruby code might want this. This
is
> similar to, but not the same as the way wxPython and wxPerl deal with 
> this.
I think this makes sense to me!  Thanks for carrying the torch while 
I''ve been overwhelmed, Alex.  Great work.

Roy