Fwd: KHTMLPart usage

[Andras Mantia]

Oops, you're right. This now makes sense. I felt that there is something wrong 
in my code....

Andras

On 2002. October 24., Thursday 11:25, Simon Hausmann wrote:
> On Thu, Oct 24, 2002 at 09:39:26AM +0300, Andras Mantia wrote:
> > Hi,
> >
> >  I was asking this on KDE-Devel, but seems that all the guys who know the
> > KHTML internals are unsubscribed from there. :-( I tend to ask you here,
> > and sorry if it is OT, I won't do anymore.
> >
> > Andras
> >
> > ----------  Forwarded Message  ----------
> >
> > Subject: KHTMLPart usage
> > Date: 2002. October 22., Tuesday 16:47
> > From: Andras Mantia <amantia at virtualartisans.com>
> > To: kde-devel at kde.org
> >
> > Hi,
> >
> >  In Quanta we have the KHTMLPart embedded for previewing the document.
> > Actually a class (WHTMLPart) is embedded which inherits from KHTMLPart.
> > Previously there was some problems with framesets, like the target = _top
> > was not handled correctly. After searching in docs, I've found that there
> > is a need to reimplement the KHTMLPart::createPart(...) in this case. So
> > I've done it, and now the reimplemented method is simply:
> >
> > KParts::ReadOnlyPart *WHTMLPart::createPart( QWidget *parentWidget, const
> >  char *widgetName, QObject *parent, const char *name, const QString
> >  &mimetype, QString &serviceName, QStringList &serviceTypes, const
> >  QStringList &params) {
> >    return new WHTMLPart(widget());
>
> I think that should look like
>
> return new WHTMLPart( parentWidget, widgetName, parent, name );
>
> (there's a reason why those arguments are passed and it's a good
> thing to pass those from your WHTMLPart constructor down to
> KHTMLPart then :-)
>
> > }
> >
> > Now the frames in the preview are working, but I'm a little afraid that
> > this caused a memory leak. When will the new WHTMLPart be freed? Do I
> > need to free it manually and if yes, when and how do you know how many
> > were created (and of course I need to have the pointer values than). Or
> > do I need to store the returned values in order to free them up
> > correctly?
>
> The created object is owned by the parent passed with the createPart
> function, so you don't need to care about memory management.
>
> Simon