[Kde-bindings] Qyoto memory problem

[Dimitar Dobrev]

    Hi, Jordan,
    

    I checked your piece of code and reproduced the issue. Then I moved GC.Collect(); after the AddTopLevelItem call and could not reproduce it any more. So it seems that the Add... methods do change ownership but the root was cleaned up by the GC because nobody owned it yet.
    About your remark: I am predominantly a .NET programmer and I couldn't agree with you more. Unfortunately, you are also correct that it is very hard to implement. It is part of the ongoing work on Qyoto but it is really quite a task. However, in this particular case I believe there may be a bug because the GC shouldn't touch the unmanaged code. That is, the reason your tree items disappear is that the underlying Qt objects are destroyed and thus the managed QTreeWidgetItem objects actually wrap nothing. I'll look into that tomorrow and in the weekend. Thanks for reporting and for your examples.

    Best regards,
    Dimitar



________________________________
 From: Jordan Miner <jminer7 at gmail.com>
To: Dimitar Dobrev <dpldobrev at yahoo.com>; KDE bindings for other programming languages <kde-bindings at kde.org> 
Sent: Thursday, February 14, 2013 9:58 PM
Subject: Re: [Kde-bindings] Qyoto memory problem
 
Hi Dimitar,

Thanks for looking at it. I tried using `new QTreeWidgetItem(root)`,
but it did not make a difference.

It might be a hard problem to solve, but ideally, Qt would act like a
.NET library. In a .NET library, you don't have to think about whether
an object has ownership of another, because as long as there is a
reference to the object, it won't get collected. All other .NET
libraries that I've used, including System.Windows.Forms, are fully
garbage collected (and you cannot write code with them where a
GC.Collect() can change behavior). In the code below, ideally, the
signal-slot connection would keep the wrapper object alive. Is this
difficult to implement?

class Test2 : QMainWindow
{
    class Wrapper : QObject
    {
        Action dg;
        public Wrapper(Action dg)
        {
            this.dg = dg;
        }
        [Q_SLOT]
        public void Invoke()
        {
            dg();
        }
    }

    public Test2()
    {
        QPushButton button = new QPushButton("Push Me!");

        var wrapper = new Wrapper(delegate
        {
            QMessageBox.Information(this, "Clicked", "You clicked the
button.", QMessageBox.StandardButton.Ok);
        });
        Connect(button, SIGNAL("clicked()"), wrapper, SLOT("Invoke()"));
        wrapper = null;
        GC.Collect();

        CentralWidget = button;
        Show();
    }

    [STAThread]
    public static int Main(String[] args)
    {
        new QApplication(args);
        new Test2();
        return QApplication.Exec();
    }
}

Thanks again,
Jordan

On Thu, Feb 14, 2013 at 9:57 AM, Dimitar Dobrev <dpldobrev at yahoo.com> wrote:
>
>     Hello,
>
>     The Qt docs are a bit vague about whether addChild and similar functions
> change the ownership of the passed object. However, in the chapter for
> QTreeWidgetItem they do give the following:
>
> Items are usually constructed with a parent that is either a QTreeWidget
> (for top-level items) or a QTreeWidgetItem (for items on lower levels of the
> tree). For example, the following code constructs a top-level item to
> represent cities of the world, and adds a entry for Oslo as a child item:
>
>      QTreeWidgetItem *cities = new QTreeWidgetItem(treeWidget);
>      cities->setText(0, tr("Cities"));
>      QTreeWidgetItem *osloItem = new QTreeWidgetItem(cities);
>      osloItem->setText(0, tr("Oslo"));
>      osloItem->setText(1, tr("Yes"));
>
>     So you may try explicitly giving a parent to your items. I myself will
> test your example later today.
>
>     Regards,
>     Dimitar Dobrev
>
> ________________________________
> From: Jordan Miner <jminer7 at gmail.com>
> To: kde-bindings at kde.org
> Sent: Thursday, February 14, 2013 5:37 PM
> Subject: [Kde-bindings] Qyoto memory problem
>
> Hi,
>
> I'm having a problem that seems like a bug in Qyoto. When I run the
> following code, usually (not always) I see a tree with two items under
> the root item. When I uncomment the GC.Collect(), one or both of the
> items no longer appear. It seems like the sub-items are getting
> garbage collected after they are added to the root item, but before
> the root item is added to the tree. The root item isn't keeping them
> from being collected like it should.
>
> I also ran into another instance of an object being collected when it
> shouldn't be, but I'll post it later.
>
> I'm currently using the .NET Framework (not Mono) on Windows XP.
>
> using System;
> using System.Collections.Generic;
> using QtCore;
> using QtGui;
>
> class Test1 : QMainWindow
> {
>     public Test1()
>     {
>         QTreeWidget treeWidget = new QTreeWidget();
>         QTreeWidgetItem root = new QTreeWidgetItem();
>         root.SetData(0, (int)Qt.ItemDataRole.DisplayRole, "Root Item");
>
>         QTreeWidgetItem item = new QTreeWidgetItem();
>         item.SetData(0, (int)Qt.ItemDataRole.DisplayRole, "Item #1");
>         root.AddChild(item);
>         item = new QTreeWidgetItem();
>         item.SetData(0, (int)Qt.ItemDataRole.DisplayRole, "Item #2");
>         root.AddChild(item);
>         //GC.Collect();
>         treeWidget.AddTopLevelItem(root);
>
>         CentralWidget = treeWidget;
>         Show();
>     }
>
>     [STAThread]
>     public static int Main(String[] args)
>     {
>         new QApplication(args);
>         new Test1();
>         return QApplication.Exec();
>     }
> }
>
> Thanks,
> Jordan
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
>
>
> _______________________________________________
> Kde-bindings mailing list
> Kde-bindings at kde.org
> https://mail.kde.org/mailman/listinfo/kde-bindings
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-bindings/attachments/20130214/3e3ee933/attachment-0001.html>