QTableWidgetItem parenting issue in table

edited July 2015 in Ruby Scripting

Elements of my QTableWidget are disappearing...

My limited understanding of RBA is that it uses a proxy to keep track of references to Qt objects created by Ruby. It does this by keeping track of the parent used when creating a widget.

I am creating a table with each cell populated with a QTableWidgetItem. According to the API QTableWidgetItem.new() is done without an argument of the item's parent. I believe this is the cause of some strange behavior. Cells of my table suddenly no longer have contents.

While I don't claim to fully understand this, I have attached code that demonstrates the behavior I see.

require 'Qt'

APP ||= RBA::Application::instance

class C < RBA::QDialog
    include RBA

    def initialize
        @table = QTableWidget.new(self)
        @btn   = QPushButton.new('push me', self)
        @btn.clicked { puts get_item(0,0).text }
        @items = []
    end

    def new_item(str)
        item = QTableWidgetItem.new(str, 0)
        # UNCOMMENT THIS TO AVOID DISAPPEARING TABLE ENTRIES.
        #@items << item
        item
    end

    def build_table
        @table.setColumnCount(2)
        @table.setRowCount(2)
        @table.setItem(0, 0, new_item('row 0 col 0'))
        @table.setItem(0, 1, new_item('row 0 col 1'))
        @table.setItem(1, 0, new_item('row 1 col 0'))
        @table.setItem(1, 1, new_item('row 1 col 1'))
    end

    def get_item(row, col)
        item = @table.item(row, col)
        raise "item at row #{row} col #{col} is nil!!!\n" unless item
        item
    end
end
c = C.new
c.build_table
GC.start
c.show

APP.exec

Run the above this way: klayout -r table_item_free_bug.rb

You'll note the I force a garbage collect after building the table. You'll note a line to be uncommented to force what looks like better behavior.

I think the way the QTableWidgetItems should work should not require a secondary reference to each item as is needed here.

What do you think? Matthias? Anyone?

Comments

  • edited November -1

    Hi Dave,

    it's an ugly feature of the Ruby to C++ interface that I have to tell Ruby if an object's ownership is being transferred. I basically have to declare every method which is known to take this ownership. Only by doing so, Ruby can be told to stop managing the objects and let Qt do that. setItem is one of those candidates. That's a bit of an effort given the number of classes and methods within Qt.

    I have included setItem into that list already, so the current 0.24 snapshot no longer shows that issue. I see it's high time to release that one now.

    The workaround you have given is a valid one. It's even backward compatible, but ugly, I admit. In the future, there will be a general method on all objects which allow telling Ruby (or Python) to stop managing the objects called "_unmanage". But of course, that should not be necessary if the methods are declared properly.

    Thanks for providing that nice test case.

    Matthias

  • edited November -1

    Hi Matthias,

    Thanks for the information. I will try _unmanage when I have a chance to recompile. FYI: the 0.24
    python eval version did not have _unmanage in it or I do not understand how to invoke it.

    The management of memory between C++ and Ruby is tough. What made me lean toward KLayout was partly
    your web-page RBA discussion of this point. I then knew you understood how important it was.

    Dave

  • edited July 2015

    If I understand correctly, I think _unmanage is not available yet even in 0.24-python-eval. Perhaps in a future version of KL.

  • edited November -1

    Oh sorry - the "Python eval" does not have it.

    The current 0.24 does. I'm referring to the snapshot (http://www.klayout.de/build.html), but I'm aware not everybody likes to compile applications, specifically not on Windows.

    I'm quite close to releasing 0.24. Give me a few more days.

    Thanks,

    Matthias

  • edited July 2015

    Thanks Davidnhutch and Matthias. When I have time I will try another version of 0.24.

    Dave

Sign In or Register to comment.