Trolltech Home | Qt-interest Home | Recent Threads | All Threads | Author | Date
All threads index page 3

Qt-interest Archive, January 2008
SIGNALS and SLOTS using custom classes

Pages: Prev | 1 | 2 | 3 | Next
Message 16 in thread

On Tuesday 22 January 2008 22:19:22 Dmitry Nezhevenko wrote:
> On Tue, Jan 22, 2008 at 12:11:52AM +0100, Eric Methorst wrote:
> > Well, thanks, I've thought of that, but that would require me to set
> > every TreeViewItem in the control. That seems a bit prohibitive.
> > Especially since I would have to control when to enable or disable that
> > (when some LineEdit is being edited etc).
> >
> > There should be a an easy way, I'd rather think.
>
> First way is to do some hacking with event filtering. However as for me
> it's very ugly.
Personally, I'd consider using the eventfilter less ugly than en/dis-abling 
all the items in the tree whenever someone starts or stops editing. That's a 
matter of taste I suppose...

I got it to work thanks to another tip. Though I'm thinking the OK button 
might be a better place to do the checking. Still, it's good to know this 
works in case I need it some other time.
>
> Try to look to Qt Model/View framework. You will be able to save some
> memory if your tree is too big.
Fortunately, not an issue.
>
> QAbstractItemModel::flags() is correct method to set/unset
> Qt::ItemIsSelectable flag.
>
> P.S. Internally QTreeWidget extends QTreeView
Yes I know: it's in the documentation.

Thanks for the help &
happy coding,
Eric

--
 [ signature omitted ]
Message 17 in thread

Hi Frank,

unfortunately I have no chance to look at your source right now, but did 
you start an event-loop in your receiving Thread (QThread::exec()) ?

Regards,
Malte


--
 [ signature omitted ]
Message 18 in thread

Hi,
when i comment out the qDebug line in the copy constructor 
or use the qDebug("...") call, the receiver slot is called.

data.h
....
	Data( const Data & d ) {
		qDebug("Data:Data copy constructor");// << this;
		//qDebug() << "Data:Data copy constructor" << this;
		i = d.i;
	}
	int i; 
...
QT4.3.2 
MSVC2003

--
 [ signature omitted ]
Message 19 in thread

Hi Joachim,

you are right! When I comment out the debug output the receiver slot is
called!! And not only in the small test example, even in my software the
slot of the MainWindow is called.

Hmm.. That's strange. What could be the reason for that. So one has to take
care where to put debug output. Even worse: Debug output can make the
program go wrong...

Bye,
Frank


Hecht, Joachim, OPES54 wrote:

> Hi,
> when i comment out the qDebug line in the copy constructor
> or use the qDebug("...") call, the receiver slot is called.
> 
> data.h
> ....
> Data( const Data & d ) {
> qDebug("Data:Data copy constructor");// << this;
> //qDebug() << "Data:Data copy constructor" << this;
> i = d.i;
> }
> int i;
> ...
> QT4.3.2
> MSVC2003
> 
> --
> J.
> 
>> -----UrsprÃngliche Nachricht-----
>> Von: Frank [mailto:frank.t.winter@xxxxxxxxx]
>> Gesendet: Sonntag, 20. Januar 2008 23:29
>> An: qt-interest@xxxxxxxxxxxxx
>> Betreff: Re: SIGNALS and SLOTS using custom classes
>> 
>> Dimitri!
>> 
>> I am sorry for the last long version. I was afraid not to
>> reproduce the error without the facilities I use (Plugins,
>> Factories). But it can be reproduced without Plugins and Factories.
>> 
>> When using a "class" in the SIGNAL the receiver SLOT does not
>> get called when emitting the SIGNAL from insider the
>> WorkerThread. When using a "struct" it gets called.
>> 
>> I compiled the most minimal code that occured to me from scratch:
>> 
>> www.ifh.de/~fwinter/test.tgz
>> 
>> cd test
>> qmake
>> make
>> ./app
>> 
>> In this version the "class" is used, i.e. the receiver slot
>> is not being called. Comment out the class and uncomment the
>> struct in file "data.h" and make the project again. Then it works.
>> 
>> make
>> ./app
>> 
>> 
>> Frank
>> 
>> 
>> 
>> 
>> Dimitri wrote:
>> 
>> > Hi,
>> > 
>> >> I tried to compile a minimum example. But, the software is in very
>> >> minimal state. It contains just the motor and some GUI to
>> use it. So
>> >> compiling a more minimum example of it is hard.
>> > 
>> > It shouldn't be that, try keepign less than 50 lines that
>> are directly
>> > related to the problem. Discard images, the GUI, etc.
>> > 
>> > --
>> > Dimitri
>> 
>> --
>> To unsubscribe - send a mail to
>> qt-interest-request@xxxxxxxxxxxxx with "unsubscribe" in the
>> subject or the body.
>> List archive and information: http://lists.trolltech.com/qt-interest/
>> 
>> 
> 
> --
> To unsubscribe - send a mail to qt-interest-request@xxxxxxxxxxxxx with
> "unsubscribe" in the subject or the body. List archive and information:
> http://lists.trolltech.com/qt-interest/

--
 [ signature omitted ]
Message 20 in thread

Hi,

> I compiled the most minimal code that occured to me from scratch:
> 
> www.ifh.de/~fwinter/test.tgz

I've built and run your example with Qt 4.4 on Linux.

The output is:
	$ ./app
	Debug: Data:Data copy constructor 0xb7cba330
	Debug: Data:Data copy constructor 0x8167160
	Warning: QMutex::lock: Deadlock detected in thread -1211389040
and then the program freezes.

Which version of Qt are you using on which platform?

--
 [ signature omitted ]
Message 21 in thread

Dimitri!

I use Qt 4.3.2 on Linux, my output is the same without "Warning:
QMutex::lock: Deadlock detected in thread". The program freezes, but it
does not freeze when removing the "qDebug() <<" line.  Then the receiver
slot gets called.

Strange!


Frank







Dimitri wrote:

> Hi,
> 
>> I compiled the most minimal code that occured to me from scratch:
>> 
>> www.ifh.de/~fwinter/test.tgz
> 
> I've built and run your example with Qt 4.4 on Linux.
> 
> The output is:
> $ ./app
> Debug: Data:Data copy constructor 0xb7cba330
> Debug: Data:Data copy constructor 0x8167160
> Warning: QMutex::lock: Deadlock detected in thread -1211389040
> and then the program freezes.
> 
> Which version of Qt are you using on which platform?
> 
> --
> Dimitri

--
 [ signature omitted ]
Message 22 in thread

Hi,

> I use Qt 4.3.2 on Linux, my output is the same without "Warning:
> QMutex::lock: Deadlock detected in thread". The program freezes, but it
> does not freeze when removing the "qDebug() <<" line.  Then the receiver
> slot gets called.
> 
> Strange!

The relevant code has been reworked, possibly between Qt 4.3.2 and Qt 4.3.3. I 
really don't know at this point whether the deadlock warning is supposed to 
point to errors in user code, or maybe to detect errors in Qt.

It would help if you could strip down your program a bit more. I'm currently 
unable to understand the structure of the program - unless I spend significant 
time on it which I can't.

--
 [ signature omitted ]
Message 23 in thread

On Tue, Jan 22, 2008 at 07:41:28PM +0100, Dimitri wrote:
> Hi,
>
>> I use Qt 4.3.2 on Linux, my output is the same without "Warning:
>> QMutex::lock: Deadlock detected in thread". The program freezes, but it
>> does not freeze when removing the "qDebug() <<" line.  Then the receiver
>> slot gets called.
>>
>> Strange!
>
> The relevant code has been reworked, possibly between Qt 4.3.2 and Qt 
> 4.3.3. I really don't know at this point whether the deadlock warning is 
> supposed to point to errors in user code, or maybe to detect errors in 
> Qt.

I have just spend a bit time with provided code. Now I'm pretty sure that
this is Qt bug (or maybe a feature :) ).

Attaching to provided example using GDB shows followed (Qt 4.3.3):

Thread 2 (Thread 0xb6c6bb90 (LWP 4507)):
#0  0xb769c820 in pthread_cond_wait@@GLIBC_2.3.2 () from
/lib/libpthread.so.0
#1  0xb76ec7a4 in QWaitCondition::wait () from /usr/lib/libQtCore.so.4
#2  0xb76e7c9b in QReadWriteLock::lockForWrite () from
/usr/lib/libQtCore.so.4
#3  0xb77b3939 in QObject::~QObject () from /usr/lib/libQtCore.so.4
#4  0xb775262e in ?? () from /usr/lib/libQtCore.so.4
#5  0x0808f214 in ?? ()
#6  0xb756eff4 in ?? () from /lib/libc.so.6
#7  0xb7570140 in ?? () from /lib/libc.so.6
#8  0x0808db18 in ?? ()
#9  0xb781bc30 in ?? () from /usr/lib/libQtCore.so.4
#10 0x0808f210 in ?? ()
#11 0xb6c6ac98 in ?? ()
#12 0xb7752a2d in QTextStream::~QTextStream () from
/usr/lib/libQtCore.so.4
Backtrace stopped: frame did not save the PC

Thread 1 (Thread 0xb70a96c0 (LWP 4506)):
#0  0xb74f25fd in poll () from /lib/libc.so.6
#1  0xb72ec5d6 in ?? () from /usr/lib/libglib-2.0.so.0
#2  0x0808e2a0 in ?? ()
#3  0x00000003 in ?? ()
#4  0xffffffff in ?? ()
#5  0x0808e2a0 in ?? ()
#6  0x00000003 in ?? ()
#7  0xb7359a20 in ?? () from /usr/lib/libglib-2.0.so.0
#8  0xb7359a60 in ?? () from /usr/lib/libglib-2.0.so.0
#9  0xbfe836b4 in ?? ()
#10 0x00000001 in ?? ()
#11 0x00000001 in ?? ()
#12 0x08054c90 in ?? ()
#13 0x0808e2a0 in ?? ()
#14 0xb74f2590 in ?? () from /lib/libc.so.6
#15 0xb769bbc0 in ?? () from /lib/libpthread.so.0
#16 0xb769a330 in ?? () from /lib/libpthread.so.0
#17 0xb730bf32 in g_thread_self () from /usr/lib/libglib-2.0.so.0
#18 0xb72ecb5e in g_main_context_iteration () from
/usr/lib/libglib-2.0.so.0
#19 0xb77c4072 in QEventDispatcherGlib::processEvents () from
/usr/lib/libQtCore.so.4
#20 0xb79bf125 in ?? () from /usr/lib/libQtGui.so.4
#21 0x08052710 in ?? ()
#22 0xbfe83728 in ?? ()
#23 0x00000000 in ?? ()
#0  0xb74f25fd in poll () from /lib/libc.so.6


Currently I have no debug version of Qt, however QTextStream destructor
can be called only from qDebug() call. 

Adding some printf/qDebug after emiting signal (that has only one
connected slot with Qt::QueuedConnection) shows that thread is freezed
somewhere in emit call.

Also I've tried to create smaller example to reproduce it.

Expected behaviour: app should NOT freeze. and slot should not be called
(since we have no event loop here).

After changing Queued connection to Direct and/or removing qDebug() from copy 
constructor makes example workable.

// --------- foo.h
#ifndef MY_H
#define MY_H

#include <QtDebug>
#include <QObject>

class Data
{
public:
        Data(bool c) : content_(c) { }
        Data() { }
        virtual ~Data() { }
        Data(const Data& other)
        {
                qDebug() << "copy constructor";
                content_=other.content();
        }
        inline bool content() const { return content_; }
private:
        bool content_;
};

class Foo: public QObject
{
        Q_OBJECT
public:
        Foo() { }
        virtual ~Foo() { }
        void test(const Data& data)
        {
            qDebug() << "Emiting signal";
            emit someSignal(data);
        }
public slots:
        void someSlot(const Data&)
        {
                qDebug() << "Got signal";
        }
signals:
        void someSignal(const Data&);
};

#endif

// ----- foo.cpp
#include <QCoreApplication>
#include <QtDebug>
#include <QMetaType>

#include "foo.h"

int main(int argc, char* argv[])
{
        QCoreApplication app(argc, argv);
        qRegisterMetaType<Data>("Data");

        Data data(true);
        Foo* foo=new Foo();
        QObject::connect(foo, SIGNAL(someSignal(const Data&)), foo, SLOT(someSlot(const Data&)), Qt::QueuedConnection);
        foo->test(data);
	qDebug() << "foo::test() finished";
}


-- 
 [ signature omitted ]

Attachment: signature.asc
Description: Digital signature

Message 24 in thread

Hi,

> I have just spend a bit time with provided code. Now I'm pretty sure that
> this is Qt bug (or maybe a feature :) ).

Then please file a bug report, so that developers are aware of the problem and 
can fix it in an upcoming release:
	http://trolltech.com/bugreport-form

I will also try to look into your minimal example myself, time permitting...

--
 [ signature omitted ]
Message 25 in thread

> I will also try to look into your minimal example myself, time 
> permitting...

Here's proof that you should always try to strip down to a really *minimal* 
example that reproduces the problem.

I can reproduce the problem:
* without threads,
* without a custom class,
* without actually any signal argument.
This should give some clues...


// --------- foo.h
#ifndef FOO_H
#define FOO_H

#include <QObject>
#include <iostream>

class Foo: public QObject
{
     Q_OBJECT
public:
     void test()
     {
         std::cerr << "Emitting signal" << std::endl;
         emit someSignal();
     }
public slots:
     void someSlot()
     {
         std::cerr << "Got signal" << std::endl;
     }
signals:
     void someSignal();
};

#endif

// ----- foo.cpp
#include "foo.h"
#include <QCoreApplication>
#include <iostream>

int main(int argc, char* argv[])
{
     QCoreApplication app(argc, argv);

     Foo foo;
     QObject::connect(&foo, SIGNAL(someSignal()), &foo, SLOT(someSlot()), 
Qt::QueuedConnection);
     foo.test();
     std::cerr << "foo::test() finished" << std::endl;
}

--
 [ signature omitted ]
Message 26 in thread

Dimitri wrote:
>Here's proof that you should always try to strip down to a really
> *minimal* example that reproduces the problem.

There's no problem with the code you pasted. The application doesn't 
freeze.

-- 
 [ signature omitted ]

Attachment: signature.asc
Description: This is a digitally signed message part.

Message 27 in thread

Thiago Macieira wrote:
> Dimitri wrote:
>> Here's proof that you should always try to strip down to a really
>> *minimal* example that reproduces the problem.
> 
> There's no problem with the code you pasted. The application doesn't 
> freeze.

There *is* a problem: the slot is not called with Qt::QueuedConnection because 
there's no event loop. That's the problem Frank initially reported.

--
 [ signature omitted ]
Message 28 in thread

Dimitri wrote:
>Thiago Macieira wrote:
>> Dimitri wrote:
>>> Here's proof that you should always try to strip down to a really
>>> *minimal* example that reproduces the problem.
>>
>> There's no problem with the code you pasted. The application doesn't
>> freeze.
>
>There *is* a problem: the slot is not called with Qt::QueuedConnection
> because there's no event loop. That's the problem Frank initially
> reported.

That's not a problem in Qt. That's the expected behaviour.

But Dmitry's code does show a bug in Qt.

-- 
 [ signature omitted ]

Attachment: signature.asc
Description: This is a digitally signed message part.

Message 29 in thread

Hi,

> That's not a problem in Qt. That's the expected behaviour.

Yes, that would be a problem in code that's using Qt, not in Qt.
There are two separate issues here:
* Qt::QueuedConnection won't work without event loop,
* additionally Dmitry's code shows a bug in Qt.

> But Dmitry's code does show a bug in Qt.

You probably mean Frank's code?

--
 [ signature omitted ]
Message 30 in thread

On Wed, Jan 23, 2008 at 11:19:53PM +0100, Dimitri wrote:
>> I will also try to look into your minimal example myself, time  
>> permitting...
>
> Here's proof that you should always try to strip down to a really 
> *minimal* example that reproduces the problem.
>
> I can reproduce the problem:
> * without threads,
> * without a custom class,
> * without actually any signal argument.
> This should give some clues...

My example already has no threads.
Custom class is _required_ to reproduce it, since bug is reproduceable
only if qDebug() is called from copy constructor.

I will fill bugreport tomorrow.

-- 
 [ signature omitted ]

Attachment: signature.asc
Description: Digital signature

Pages: Prev | 1 | 2 | 3 | Next