[wxruby-users] wxruby 1.9.9 menu - strange corruption

[Mario Steele]

Hello Ridge,

Let me explain this a bit further in detail as to the process the Garbage
Collector, and wxRuby's own classes work about things.

On Sun, Jan 4, 2009 at 5:22 PM, Ridge Mcghee <lists at ruby-forum.com> wrote:

> Thanks for your response.
>
>   Good suggestion (1) and that is actually what I did to move forward.
>   However, I consider it a work-around.  I welcome your explanations
>   because I want to understand.
>
>   Here's my view:
>   As a developer, I don't want just the "native" superclass to work
>   properly with the GC.  I want my sub-classes to work properly, too.
>   (e.g., my sub-class should inherit the reference count or whatever
>   to make it a fully-qualified class, huh?)  If I understood your
>   message, the GC is making decisions based on the type (MenuItem).
>   Isn't this just what an object-oriented system should *not* do?


What Alex was trying to explain here, is that some classes, such as Menu,
MenuItem, Rect, Point, and various other ones, are considered Information
Classes.  Information classes only hold the information of what is relevent
at the point and time of the execution of the code.  To make it a bit more
clearer to understand, let's take the problem of MenuItem.  Imagine that
MenuItem is a Ruby Struct class.

Defining it as such:

MenuItem = Struct.new(:title,:id,:parent,:bitmap)

my_new_menu_item =
MenuItem.new("&Open",Wx::ID_OPEN,my_file_menu,Wx::ICON_FOLDER)

This is a silly mockup of what I'm trying to explain, but this is what it
boils down to.  Once you actually create the control, there's no further
need to reference this control, till something happens with it, such as
evt_menu(Wx::ID_OPEN), this is where we re-retrive the actual wxRuby
control, for any association needed to do special things, such as changing
the title of the Menu item.  There is no other things you can really do with
a MenuItem, aside from either updating it, or deleting it.  Atleast, as far
as wxWidgets is concerned.  Therefore, if you don't store the instance of
the MenuItem in a variable, where the Garbage Collector can see that it is
still being referenced within your code, Ruby thinks that it is no longer
needed, and therefore frees it up for others to use.

  Some questions:
>   Is this a generic ruby issue (or is it unique to wxruby)?


This is a unique problem with wxRuby.  It's mainly a decision of what we
need to continue to keep tracking, without tracking every single object
created.

  What triggers the GC ?  (While testing, I found that the "rewrapping"
>   occurred whether or not I called find_item.  Just repeatedly
> selecting
>   the MyMenuItem, which triggered a menu_event and caused on_menu_event
>   to be called, would result in the MyMenuItem being "rewrapped" as a
>   MenuItem.  As such, over-riding MyMenu#find_item would not be
> expected
>   to solve the problem.)


Garbage Collection, especially in a wxRuby app, happens quite often, as
there are many times that a Ruby object is temporarly created, to associate
it with a wxWidget's object.  And 9 times out of 10, it's a temporary
reference, which is immediately de-referenced within the code, and when
Garbage Collection runs again, it'll delete this instance.  However, in the
particular instance of Menu Event (evt_menu), there is no particular
reference to review to say, Oh, this needs to be referenced by previous
instance creation.

  I appreciate your offer to "have a look" and I'd be interested to
>   know whatever you find out.


Unfortunately, in this case, the procedure that Alex has referenced, would
be the best way, as it would be nearly neigh improbable to track every
single custom class creation, between wxWidgets and wxRuby.  As with
wxWidgets, there's nothing to allow us to track custom classes created in
Ruby of wxWidgets classes, least we create a new memory structure, that
would inherit from one of our classes.  It may be doable, in the Ruby level,
at the actual Ruby level itself, but not on the C++ Side.

Cheers,
> Ridge
>
>
> --
> Posted via http://www.ruby-forum.com/.
> _______________________________________________
> wxruby-users mailing list
> wxruby-users at rubyforge.org
> http://rubyforge.org/mailman/listinfo/wxruby-users
>



-- 
Mario Steele
http://www.trilake.net
http://www.ruby-im.net
http://rubyforge.org/projects/wxruby/
http://rubyforge.org/projects/wxride/
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://rubyforge.org/pipermail/wxruby-users/attachments/20090104/40be3364/attachment-0001.html>