[Kde-bindings] Fwd: Re: Qt's parent and child objects

Adam Treat manyoso at yahoo.com
Fri Jan 10 07:32:28 UTC 2003


----------  Forwarded Message  ----------

Subject: Re: Qt's parent and child objects
Date: Friday 10 January 2003 02:31 am
From: Adam Treat <manyoso at yahoo.com>
To: Marcus <mathpup at mylinuxisp.com>, "Qt-Sharp mailing list" 
<qtcsharp-list at lists.sourceforge.net>

That is a very interesting article and will be useful when we revisit this
issue with the next major version.  I think we will have some expanded
abilities to handle memory management and object tracking since I plan on
storing a pointer to the managed proxy class in the unmanaged glue class
ctor.  I am planning on doing this via the GCHandle structure.

Question: what about non-QObjects?  Things like QString and QEvent do not
inherit QObject and so the correct strategy for managing them will have to be
different I think.  Perhaps it does not make sense to store a pointer to the
managed object in classes that do not inherit QObject ...  But then are there
any occasions where this might be necessary (object tracking and automatic
boxing) ... ?

On Friday 10 January 2003 06:15 am, Marcus wrote:
> I happened to read one of the Qt Quarterly articles tonight about Qt and
> parents and child widgets. One of the issues we have struggled with
> concerns memory management of child widgets. For example, in C++ when a
> QSlider is added to a QDialog, the QDialog becomes the slider's parent and
> will dispose of the slider when the dialog is deleted. The problem on the
> C# side is that we neeed to protect the C# wrapper from being disposed too
> early in these circumstances.
>
> As I recall, we also were a little concerned about reparenting and other
> ways that a parent widget might acquire ownership of a widget. (Normally,
> the widget's parent is specified in the constructor, so that the parent
> widget is made aware of its child at that time.)
>
> In the article, I learned that several events can be used to track this
> activity. Specifically, the ChildInsertedEvent is sent when a child is
> added to a widget, and ChildRemoved event is sent when a child is removed.
> In addition, although I begin with a discussion in terms of QWidget and its
> subclasses, these events are actually valid for any QObjects.
>
> Finally, if Qt is built with debugging support, the dumpObjectTree() and
> other similar functions are available to print out information about Qt's
> child trees. This may be useful in the future to see which objects own
> which according to Qt.
>
> http://doc.trolltech.com/qq/qq03-big-brother.html
>
>
>
>
>
>
>
> -------------------------------------------------------
> This SF.NET email is sponsored by:
> SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See!
> http://www.vasoftware.com
> _______________________________________________
> Qtcsharp-list mailing list
> Qtcsharp-list at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/qtcsharp-list

-------------------------------------------------------




More information about the Kde-bindings mailing list