One of the more difficult issues to deal with was understanding the "life cycle" of FOX objects (that is, the actual C++ objects) and their relationship to the associated Ruby instances. Understanding this relationship is critical when dealing with Ruby's garbage collector, to ensure that objects are disposed of at the right time.
For our purposes, we can divide the set of all objects in an FXRuby
program into two groups, those objects that Ruby "owns" and those that
it doesn't. The first group (the "owned" objects) includes those that you
create explicitly from Ruby code. This is usually done by calling a class'
new method, e.g.
myIcon = FXPNGIcon.new(myApp, File.open("icon.png", "rb").read) myButton = FXButton.new(parentWin, "Hello, World!", myIcon)
It's important to keep in mind that when you create an object like this you're not only creating the Ruby instance part (i.e. whatever overhead is usually associated with a Ruby instance) but a C++ FOX object as well. Because we created these objects, we would reasonably expect them to be destroyed when they are garbage-collected so that our programs don't leak memory.
The other group of objects (those not owned by Ruby) are those
returned from most class instance methods; they are references to already-
existing objects. For example,
returns a reference to the status bar's enclosed status line
FXGLGroup object owns all of the
FXGLObject objects it "contains". In other words, when that
FXGLGroup object is destroyed, it will also destroy all of the
FXGLObject objects for which it holds pointers.
In order to keep track of which GL objects have been added to an
FXGLGroup, all of the FXRuby C++ classes derived from
FXGLObject have a boolean member variable
owned that indicates whether this object is "owned" or not. Until an
FXGLObject object is added to a group, this member variable should stay false.