Events are not posted to a particular instance of an event loop object. They are posted to a thread. An event loop object does not "own" any events. It's basically a while loop that calls processEvents of a per thread event dispatcher.

That being said if you nest event loops they all process the same pile of events. It's just that only the top one gets to do it while the calling ones wait for it to return.

@sierdzio said in QWidget: Cannot create a QWidget without QApplication - OpenCV imshow() 2.4.13 ?:

Is Qt the only supported backend? If yes, then indeed requirements do propagate.

No, it has been added later on. It's maybe even the latest that has been implemented.

AFAIK, what the OP is hitting here, is that OpenCV doesn't have an implementation for imgshow for iOS. It would require to either use Qt to show the result of what he's doing or native stuff.

@SGaist I wish mean throw this message : QEventLoop: Cannot be used without QApplication

But this problem is no more. I have delete the project and create un other without dll...
It's not the best solution but it's gona work.

Hi and welcome to devnet,

Do you have any static QWidget based class in your library/application ?

I reply to my self, perhaps there is someone else which have the same kind of issue ;-)

In fact, it is quite easy, the solution is to use install an event filter on application level:

class MouseEventFilter : public QObject { Q_OBJECT public: explicit MouseEventFilter(QObject *parent = 0); signals: void recalibrateTouch(); public slots: // QObject interface public: bool eventFilter(QObject *object, QEvent *event) { if(event->type() == QEvent::MouseButtonPress) { if(m_delay.hasExpired(5000)) { m_clickCounter=0; m_delay.start(); } ++m_clickCounter; if(m_clickCounter == 10) emit recalibrateTouch(); } return QObject::eventFilter(object,event); } private: int m_clickCounter; QElapsedTimer m_delay; };

Then simply install the event filter on application level like this:

app->installEventFilter(new MouseEventFilter(qApp));

That's it :)
Regards

Thanks for sharing !

Hi, just to want add, while Qt Creator's capturing of your qDebug() output is usually 100%, but if you want to be sure to get everything, you could try running DebugView when your app exits.

No worries for that :)

Since you have it working now, please mark the thread as solved using the "Topic Tool" button so that other forum users may know a solution has been found :)

@the_

will work

Such a strong word ... it depends on the advisory locking mechanism used and most linux-es will support more than one. As duly noted in the documentation it's only guaranteed to work if the same scheme is used across all processes:

Serialization is only guaranteed if all processes that access the shared resource use QLockFile, with the same file path.

@hskoglund Thanks for the info

@SGaist
Thanks Champ, I am checking it.

Thank you all very much.

I now created a QMessageBox in the main.cpp before constructing the MainWindow as SGaist suggested.
If "no" is pressed calling QApplication::quit() does nothing, but just return 0 works perfectly fine :-)

Thanks for the response @bsomervi.

I added some trace messages to my code to follow execution and I discovered that:

Before changing to TTY both traces are shown, signal is being emitted and slot is being called. Once changed to TTY, signal keeps being emitted but slot is never called till I return to GUI.

I added, too, trace messages in some events handled by my app and none was processed once moved to TTY (focus adquired, focus lost, painting event).

I've ran tests to detect memory leaks with valgrind and nothing was shown up.

It's rarely needed to call unload.

OK, I found a solution.
Two methods have to be called in reverse order.

QStyle *style = QStyleFactory::create(styleName); QApplication::setPalette(style->standardPalette()); QApplication::setStyle(style);

And now it works as desired.

Tomas