qobject

I was digging into some source code I am working on. I found a peculiar statement that someone had coded. The source code is a GUI application with a QML GUI and uses QT 4.7.x. The snippet below belongs to core application logic. // connect signal-slots for decoupling QObject::connect (this, SIGNAL(setCurrentTaskSignal(int)), this, SLOT(SetCurrentTaskSlot(int)), Qt::QueuedConnection); It's strange that the object connects to itself via a queued connection which essentially means that the object may "live" in different threads at the same time? At first glance It didn't made any sense to me.

I made a prototype of a project with PyQt and made it work there, now I'm trying to convert it to C++ and am having some problems. If I don't put the Q_OBJECT macro in, it compiles and works, but if I comment it out, I get the following errors: Undefined symbols: "vtable for MapView", referenced from: MapView::~MapView()in mapview.o MapView::~MapView()in mapview.o MapView::MapView(QObject*)in mapview.o MapView::MapView()in mapview.o "MapView::staticMetaObject", referenced from: MapView::MapView(QObject*)in mapview.o MapView::MapView()in mapview.o Here's the header: #ifndef MAPVIEW_H #define

In Qt there is a macro that allows declaring private copy constructurs and assignment operators for classes: http://qt-project.org/doc/qt-5.0/qtcore/qobject.html#Q_DISABLE_COPY It is said that this macro should be used for all QObject (especially QWidget) derived classes. I understand how this works and why it is useful. What I do not understand: Is there any reason to repeat Q_DISABLE_COPY in my QObject derived classes while QObject already contains Q_DISABLE_COPY and through this effectively prevents my derived classes from being copied? The error message that might be printed from

I am a newbie with Qt. Most of the times Qt developers need to use signals and slots for object communication. I have seen two ways of connecting signals and slots so far. 1)QObject::connect(scrollBar, SIGNAL(valueChanged(int)),label, SLOT(setNum(int))); 2)connect(scrollBar, SIGNAL(valueChanged(int)),label, SLOT(setNum(int))); What is the exact difference between both of them? Why do we have to prefix QObject in the first method? lpapp You call the static version in both aforementioned cases, the signature of which is as follows: QMetaObject::Connection QObject::connect(const QObject * sender,

Coming from the Symbian world, I'm used to using the heap as much as possible to avoid running out of stack space, especially when handling descriptors. CBase derived classes were always dynamically allocated on the heap, since if they were not, their member variables would stay uninitialized. Does the same convention apply to QObject-derived classes? In Qt it seems to be common to put, for example QString, on the stack. Are the string contents put on the heap while QString acts as a container on the stack, or is everything put on the stack? Frank Osterfeld As sje397 said: It's idiomatic to

I am receiving the following linker error when I build my application. HIMyClass.obj:: error: unresolved external symbol "public: virtual struct QMetaObject const * __thiscall CHIMyClass::metaObject(void)const " (?metaObject@CHIMyClass@@UBEPBUQMetaObject@@XZ) File not found : HIMyClass.obj HIMyClass.obj:: error: unresolved external symbol "public: virtual void * __thiscall CHIMyClass::qt_metacast(char const *)" (?qt_metacast@CHIMyClass@@UAEPAXPBD@Z) File not found : HIMyClass.obj HIMyClass.obj:: error: unresolved external symbol "public: virtual int __thiscall CHIMyClass::qt_metacall(enum

I have a fairly complex set of C++ classes that are re-written from Java. So each class has a single inherited class, and then it also implements one or more abstract classes (or interfaces). Is it possible to use qobject_cast() to convert from a class to one of the interfaces? If I derive all interfaces from QObject , I get an error due to ambiguous QObject references. If however, I only have the base class inherited from QObject , I can't use qobject_cast() because that operates with QObject s. I'd like to be able to throw around classes between plugins and DLLs referred to by their