Hello Ridge,<br><br>Let me explain this a bit further in detail as to the process the Garbage Collector, and wxRuby's own classes work about things.<br><br><div class="gmail_quote">On Sun, Jan 4, 2009 at 5:22 PM, Ridge Mcghee <span dir="ltr"><<a href="mailto:lists@ruby-forum.com">lists@ruby-forum.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Thanks for your response.<br>
<br>
Good suggestion (1) and that is actually what I did to move forward.<br>
However, I consider it a work-around. I welcome your explanations<br>
because I want to understand.<br>
<br>
Here's my view:<br>
As a developer, I don't want just the "native" superclass to work<br>
properly with the GC. I want my sub-classes to work properly, too.<br>
(e.g., my sub-class should inherit the reference count or whatever<br>
to make it a fully-qualified class, huh?) If I understood your<br>
message, the GC is making decisions based on the type (MenuItem).<br>
Isn't this just what an object-oriented system should *not* do?</blockquote><div><br>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.<br>
<br>Defining it as such:<br><br>MenuItem = Struct.new(:title,:id,:parent,:bitmap)<br><br>my_new_menu_item = MenuItem.new("&Open",Wx::ID_OPEN,my_file_menu,Wx::ICON_FOLDER)<br><br>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. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> Some questions:<br>
Is this a generic ruby issue (or is it unique to wxruby)?</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> What triggers the GC ? (While testing, I found that the "rewrapping"<br>
occurred whether or not I called find_item. Just repeatedly<br>
selecting<br>
the MyMenuItem, which triggered a menu_event and caused on_menu_event<br>
to be called, would result in the MyMenuItem being "rewrapped" as a<br>
MenuItem. As such, over-riding MyMenu#find_item would not be<br>
expected<br>
to solve the problem.)</blockquote><div><br>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. <br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;"> I appreciate your offer to "have a look" and I'd be interested to<br>
know whatever you find out.</blockquote><div><br>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.<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Cheers,<br>
<font color="#888888">Ridge<br>
</font><div class="Ih2E3d"><br>
<br>
--<br>
Posted via <a href="http://www.ruby-forum.com/" target="_blank">http://www.ruby-forum.com/</a>.<br>
_______________________________________________<br>
</div><div><div></div><div class="Wj3C7c">wxruby-users mailing list<br>
<a href="mailto:wxruby-users@rubyforge.org">wxruby-users@rubyforge.org</a><br>
<a href="http://rubyforge.org/mailman/listinfo/wxruby-users" target="_blank">http://rubyforge.org/mailman/listinfo/wxruby-users</a><br>
</div></div></blockquote></div><br><br clear="all"><br>-- <br>Mario Steele<br><a href="http://www.trilake.net">http://www.trilake.net</a><br><a href="http://www.ruby-im.net">http://www.ruby-im.net</a><br><a href="http://rubyforge.org/projects/wxruby/">http://rubyforge.org/projects/wxruby/</a><br>
<a href="http://rubyforge.org/projects/wxride/">http://rubyforge.org/projects/wxride/</a><br>