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

[Hugh S. S. E. E. <hg...@dm...>]

On Thu, 3 Jul 2003, Lyle Johnson wrote:

> Hugh Sasse Staff Elec Eng wrote:
>
> > The next thing I'll need to know is: Where can I generalize this
> > behaviour: are there other calls that propagate like this?
>
> The other two that immediately come to mind are the detach() and
> destroy() methods.
>
> You may already understand that the purpose of calling create() is to
> create and then bind a native windowing-system entity (e.g. a X window,
> or a Win32 GDI font) to an already-existing FOX object (like an FXWindow
> or FXFont instance).

Yes, I have an idea about that, but am not au fait with the details.
I don't think I need to be yet!
>
> 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?

> And like create(), detach() does its thing recursively, from parent to
> child windows.
>
> 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[?].

> whatever that was backing it up. An important distinction, though, is
> that destroy() is not as aggressive as create() and detach() in terms of
> 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/
>
> and then associate it with two different widgets (a label and a button):
 [...]
> Now suppose that at some point later you call destroy() on the button:
 [...]
> It is clear that you want to blow away the X window (or Win32 window)
> underlying that FXButton instance, but you don't want to destroy the
> icon too since someone else may still be using that resource. And in

that flexibility is useful.
>
> There are other behaviors in FOX that are recursive, e.g. the manner in
> which the layout algorithm works, but right offhand I can't think of any
> other APIs that you'd deal with directly that have a recursive nature. I

OK, thanks, this is probably enough for now. :-)

> am sure that as soon as I send this post, someone will point out some
> cases I forgot about, though ;)
>
> Hope this helps,

Yes, thank you again.
>
> Lyle
>
        Hugh