@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

Very good ! :)

I asked the same quesion in stackoverflow. I gues I found out why I am having this problem.

http://stackoverflow.com/questions/30686488/qapplication-is-lazy-or-making-other-threads-lazy-in-the-app

OK guys, I was able to solve the problem. The Fedora people changed a configuration file, so that qDebug output wasn't shown to the user anymore, until the user changed the settings like described here:
https://bugzilla.redhat.com/show_bug.cgi?id=1227295

@SGaist Fixed it ;)

I would also add to JKSH's answer that the docs state clearly:

For any GUI application using Qt, there is precisely one QApplication object, no matter whether the application has 0, 1, 2 or more windows at any given time.
This means that your classes using a QtWindowInit object are totally wrong because each QtWindowInit instance will create a new QApplication object+instance, which will conflict with the previous one(s) (they would not know which QApplication object should manage the events) -- unless you make it static, but then other problems arise, definitely thread unsafe.
That's why in most Qt applications it is very often to find a QApplication (or QCoreApplication) object declaration in the very first lines of main(), and then forget about it at all.

Although I am not a threads expert, I can think of creating a main thread containing the QApplication object and the methods to create new widgets. Then, in the other threads of your application, you should just give the main thread a hint on which widget to create.

@shavera I understand what do you mean but honestly I don't think such kind of feature could be useful; you need anyway to do something manually to run in GUI or non-GUI mode.