Re: [Fxruby-users] Dialogues, and create.

[Lyle J. <jl...@cf...>]

Hugh Sasse Staff Elec Eng wrote:

>> Calling detach() on a FOX object reverses part of the effect of
>> create(); it breaks this binding between the FOX object and its
>> window-system entity, but it doesn't actually destroy either of them.
> 
> When would you want to do that, then?

Please see the FAQ "What's the difference between detach and delete?":

	http://www.fox-toolkit.org/faq.html#DETACH

>> Calling destroy() goes one step further (if you want to think of it that
>> way) and actually destroys the window-system entity. Note that it
>> doesn't destroy (garbage-collect) the FOX object, just the X window or
> 
> So you can call create on the FXObject to get it back again if you
> wish?  Is this common practice to reduce memory usage whilst keeping
> performance high, or something? I'm thinking in my current
> application I will have many possible dialogues, and am wondering
> about when to new()...GC or create()...destroy() or show()...hide()
> them, and what [de]merits there are of each strategy.  I think I've
> just listed them in increasing order of memory usage.  I'm not sure
> if I should worry about that at all, I expect the windowing systems
> are pretty efficient in terms of memory nowadays[?].

Yes, you can call create on the object to get it back again, but no, it 
isn't common practice to create and tear down windows to reduce memory 
use. I cannot think of a single time when I have called destroy() 
explicitly in one of my FOX applications. [As the previously referenced 
FAQ notes, destroy() gets called as a side effect when the FOX object is 
garbage-collected, but I'm excluding those cases.]

I would not worry about using this as a memory management technique. One 
way it might be useful (and I think some people have used it for this) 
is to build an application that runs continuously but doesn't always 
need to display a GUI. For example, maybe at first it does display a GUI 
and allow the user to interact, set some parameters. At some point, the 
user clicks the "Go" button and we call FXApp#destroy to tear down all 
of the GUI parts, so that the program can continue to run in the 
background even if the X server is killed or something like that. Again, 
I've never needed to do this, so I'm just going from memory here.

>> its recursive behavior. Specifically, calling destroy() on a widget will
>> not destroy any of its shared resources, like fonts or icons. Suppose
>> you create an icon:
>>
>>      anIcon = FXPNGIcon.new(getApp(), ...)
> 
> Ah, just "clicked" about getApp(), avoids repeoting a ref to the
> application object.  getApp doesn't seem to appear in the methods
> pane of http://www.fxruby.org/doc/api/

It *is* listed as a "readable" attribute of FXId:

	http://www.fxruby.org/doc/api/classes/Fox/FXId.html

which means that there's also a getApp() method that returns the same 
value. But that's a separate discussion, whether we should be listing 
both the "getter" and "setter" methods as well as the "attr_reader" and 
"attr_writer" methods in the API docs ;)

-- Lyle