[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-devel
Subject:    Re: trivial KDE program crashing
From:       Martijn Klingens <mklingens () yahoo ! com>
Date:       2001-09-09 14:48:10
[Download RAW message or body]

On Sunday 09 September 2001 08:42, George Petri wrote:
> 1. Does this mean that I should allocate KApplication's on the heap as
> well, instead of locally?

You could, but it wouldn't be automatically deleted.

In general a Qt object deletes all its children, so any Qt object that has a 
parent set to non-NULL will be properly auto-deleted.
Qt objects that have a 0 parent are top-level windows. There is a special Qt 
flag Qt::WDestructiveClose that specifies that closing such a window should 
auto-delete the widget (and hence its children). [QK]MainWindow for example 
set this flag. If you create your own top-level widget that does not inherit 
from a class that sets DestructiveClose you can (and should!) either manually 
delete the widget or set the DestructiveClose flag yourself. Pick _one_ of 
these approaches, though, doing both would cause the object to be deleted 
twice and cause another crash.

Back to your situation: you don't have to take care of deleting widgets. But 
given the auto-deletion behaviour of Qt you must make sure that Qt can delete 
the widgets. As a result, creating instances of widgets outside the heap is 
bound to fail.

Also, a QApplication doesn't have a parent object (what would the parent be 
anyway? ;-) and is thus not auto-deleted. QApp could have a behaviour similar 
to DestructiveClose and auto-delete itself, buyt AFAIK no such thing exists.
Probably because you might want to access the application object after exec() 
returns, but that's guessing from my part.

> 2. Since KDE widgets are derived from QT, do _all_ KDE widgets need to be
> allocated on the heap?

If they have a parent != 0, yes. Objects with a parent 0 can be created 
outside the heap _if_ (and ONLY _if_!) they do not have DestructiveClose set, 
which is quite rare.
This applies not only to widgets, but to any class that derives from QObject.

Other Qt classes, that are not QObjects, often provide other auto-deletion 
features, but these are often hidden behind calls like setAutoDelete() and 
not enabled by default. The Qt docs are quite clear in describing the 
deletion policy for a given Qt class.

Martijn
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

[prev in list] [next in list] [prev in thread] [next in thread]