Qt-jambi-interest Archive, September 2006
Implementing Custom Layouts in Java
Message 1 in thread
I'm having trouble implementing a custom layout in Java. I kept getting
stack dumps from the c++ side, so I finally just created a simple layout
to debug. When used as the layout for a basic QWidget (via .setLayout()),
the below layout causes a stack dump:
import com.trolltech.qt.gui.QLayoutItemInterface;
import com.trolltech.qt.gui.QVBoxLayout;
public class PlainLayout extends QVBoxLayout {
@Override
public QLayoutItemInterface itemAt(int arg0) {
return super.itemAt(arg0);
}
}
If I remove the overriden itemAt() method from the PlainLayout, then I
don't get the stack dump and the layout works (see below code)
import com.trolltech.qt.gui.QVBoxLayout;
public class PlainLayout extends QVBoxLayout {
}
I've tried disabling garbage collection on the layout itself and on the
items I'm adding to it, but neither solves the problem.
Ideas anyone?
P.S. If someone knows of a way to enable debug messages for qt-jambi
(without recompiling), that might help me get to the bottom of this.
--
[ signature omitted ]
Message 2 in thread
Percy Wegmann wrote:
> I'm having trouble implementing a custom layout in Java. I kept
> getting stack dumps from the c++ side, so I finally just created a
> simple layout to debug. When used as the layout for a basic QWidget
> (via .setLayout()), the below layout causes a stack dump:
>
> import com.trolltech.qt.gui.QLayoutItemInterface;
> import com.trolltech.qt.gui.QVBoxLayout;
>
> public class PlainLayout extends QVBoxLayout {
>
> @Override
> public QLayoutItemInterface itemAt(int arg0) {
> return super.itemAt(arg0);
> }
>
> }
Hi, Percy.
I can reproduce this bug, and it will unfortunately occur when returning
from any reimplemented virtual function that is declared in Qt Jambi and
for which the return type is an interface.
It will be fixed in the next release, and I can unfortunately not see
any convenient work arounds for it at the moment. However, if you are
able to use the itemAt() and takeAt() in an existing layout (without
reimplementing them), you should be able to avoid the bug and still
create a working layout.
Thank you for the report,
-- Eskil
Message 3 in thread
Thank you for looking into this. I'm really enjoying using Qt-Jambi, and
I've noticed from this mailing list that you and your colleagues have
positive attitudes and tend to respond to inquiries quickly and
courteously, which definitely adds to the experience. Keep up the good
work.
As to this issue, I am able to implement and use custom layouts as long as
I don't add widgets after the parent widget has become visible. So, while
this is a problem:
QWidget parent = new QWidget();
parent.setLayout(new MyCustomLayout());
parent.show();
parent.layout().addWidget(someWidget);
the below is not a problem:
QWidget parent = new QWidget();
parent.setLayout(new MyCustomLayout());
parent.layout().addWidget(someWidget);
parent.show();
It seems that this issue is tied to returning a null value from itemAt()
to the QWidget::activateRecursiveHelper(QLayoutItem *item) function.
Maybe it's something relating to returning a null pointer from Java?
Regards,
On Mon, 18 Sep 2006 00:57:28 -0500, Eskil A. Blomfeldt
<eblomfel@xxxxxxxxxxxxx> wrote:
> Percy Wegmann wrote:
>
>> I'm having trouble implementing a custom layout in Java. I kept
>> getting stack dumps from the c++ side, so I finally just created a
>> simple layout to debug. When used as the layout for a basic QWidget
>> (via .setLayout()), the below layout causes a stack dump:
>>
>> import com.trolltech.qt.gui.QLayoutItemInterface;
>> import com.trolltech.qt.gui.QVBoxLayout;
>>
>> public class PlainLayout extends QVBoxLayout {
>>
>> @Override
>> public QLayoutItemInterface itemAt(int arg0) {
>> return super.itemAt(arg0);
>> }
>>
>> }
>
> Hi, Percy.
>
> I can reproduce this bug, and it will unfortunately occur when returning
> from any reimplemented virtual function that is declared in Qt Jambi and
> for which the return type is an interface.
>
> It will be fixed in the next release, and I can unfortunately not see
> any convenient work arounds for it at the moment. However, if you are
> able to use the itemAt() and takeAt() in an existing layout (without
> reimplementing them), you should be able to avoid the bug and still
> create a working layout.
>
> Thank you for the report,
> -- Eskil
>
--
[ signature omitted ]
Message 4 in thread
Percy Wegmann wrote:
> As to this issue, I am able to implement and use custom layouts as
> long as I don't add widgets after the parent widget has become
> visible. So, while this is a problem:
>
> QWidget parent = new QWidget();
> parent.setLayout(new MyCustomLayout());
> parent.show();
> parent.layout().addWidget(someWidget);
>
> the below is not a problem:
>
> QWidget parent = new QWidget();
> parent.setLayout(new MyCustomLayout());
> parent.layout().addWidget(someWidget);
> parent.show();
>
> It seems that this issue is tied to returning a null value from
> itemAt() to the QWidget::activateRecursiveHelper(QLayoutItem *item)
> function. Maybe it's something relating to returning a null pointer
> from Java?
>
Hi, Percy.
I can't seem to reproduce this problem. Exactly which methods are you
reimplementing in your custom layout, please?
best regards,
-- Eskil
Message 5 in thread
Hi Eskil,
This problem occurs with the below test layout (same one as earlier in the
thread):
import com.trolltech.qt.gui.QLayoutItemInterface;
import com.trolltech.qt.gui.QVBoxLayout;
public class PlainLayout extends QVBoxLayout {
@Override
public QLayoutItemInterface itemAt(int arg0) {
return super.itemAt(arg0);
}
}
Regards,
Percy M. Wegmann
On Tue, 19 Sep 2006 02:27:44 -0500, Eskil A. Blomfeldt
<eblomfel@xxxxxxxxxxxxx> wrote:
> Percy Wegmann wrote:
>
>> As to this issue, I am able to implement and use custom layouts as long
>> as I don't add widgets after the parent widget has become visible.
>> So, while this is a problem:
>>
>> QWidget parent = new QWidget();
>> parent.setLayout(new MyCustomLayout());
>> parent.show();
>> parent.layout().addWidget(someWidget);
>>
>> the below is not a problem:
>>
>> QWidget parent = new QWidget();
>> parent.setLayout(new MyCustomLayout());
>> parent.layout().addWidget(someWidget);
>> parent.show();
>>
>> It seems that this issue is tied to returning a null value from
>> itemAt() to the QWidget::activateRecursiveHelper(QLayoutItem *item)
>> function. Maybe it's something relating to returning a null pointer
>> from Java?
>>
> Hi, Percy.
>
> I can't seem to reproduce this problem. Exactly which methods are you
> reimplementing in your custom layout, please?
>
> best regards,
> -- Eskil
>
--
[ signature omitted ]
Message 6 in thread
Percy Wegmann wrote:
> This problem occurs with the below test layout (same one as earlier in
> the thread):
>
> import com.trolltech.qt.gui.QLayoutItemInterface;
> import com.trolltech.qt.gui.QVBoxLayout;
>
> public class PlainLayout extends QVBoxLayout {
>
> @Override
> public QLayoutItemInterface itemAt(int arg0) {
> return super.itemAt(arg0);
> }
>
> }
Hi, Percy.
If you override QLayout.itemAt(), you can expect to get a crash whenever
the function is called internally. Since the nature of the bug is memory
corruption, the manifestation of the crash (behavior, time and code
path) may seem somewhat arbitrary, but I would recommend that you do not
override itemAt() nor takeAt() until the third technical preview is out,
since the bug has been fixed there. :-)
-- Eskil
