Does Qt-based dll can be used by another non qt-based app (without QApplication)?
-
Hello!
I`m working on qt-based DLL for mailing (SMTP/MAPI protocols). This DLL will be used in non qt-based applications also (no QApplication creates). DLL have c++ interface, but inside it use QtNetwork module (QTcpSocket/QSslSocket etc).
No QtGui, only Qt-core and QtNetwork modules. Does qt manage events properly in that case and is that correct approach? (which troubles may occur). Using that DLL are threadsafe?
(if using of qt is impossible, please advise the appropriate libraries for crossplatform smtp mailing).
Thx! -
Hello!
I`m working on qt-based DLL for mailing (SMTP/MAPI protocols). This DLL will be used in non qt-based applications also (no QApplication creates). DLL have c++ interface, but inside it use QtNetwork module (QTcpSocket/QSslSocket etc).
No QtGui, only Qt-core and QtNetwork modules. Does qt manage events properly in that case and is that correct approach? (which troubles may occur). Using that DLL are threadsafe?
(if using of qt is impossible, please advise the appropriate libraries for crossplatform smtp mailing).
Thx!Hi @meteoir, you can use a Qt-based DLL in a non-Qt-based app.
However, Qt Network requires QCoreApplication and you must call QCoreApplication::exec() to run an event loop.
You should use all of the Qt classes in their own thread. See https://stackoverflow.com/questions/22289423/how-to-avoid-qt-app-exec-blocking-main-thread/22290909#22290909 (This post talks about a Qt GUI, but you can follow the same steps for Qt Network)
-
ok, but if I can
t use QCoreApplication? Im already test my mailing DLL in non-qt-based app. It works, but I don't know what kind of troubles may occur in future. And how can I resolve thread-safety problem in that case?@meteoir said in Does Qt-based dll can be used by another non qt-based app (without QApplication)?:
ok, but if I can
t use QCoreApplication? Im already test my mailing DLL in non-qt-based app. It works, but I don't know what kind of troubles may occur in future.Are you using the
waitFor*methods for the socket classes? These might work without QCoreApplication, but I'm not 100% sure.Why can't you use QCoreApplication?
how can I resolve thread-safety problem in that case?
Make sure you only call the Qt functions from 1 thread only. It doesn't need to be the main thread, but it needs to be the same thread all the time.
-
Yes, I'm using waitForConnected/waitForReadyRead/waitForBytesWritten/waitForEncrypted functions. How can I test your suggestion? (working without QCoreApplication).
I can't use QCoreApplication, because its't not allowed by usage scenarios.
I'm afraid that I need thread-safety in scenario, when mailing DLL will called by different applications at the same time. May be I need messages queue or something like that? -
Yes, I'm using waitForConnected/waitForReadyRead/waitForBytesWritten/waitForEncrypted functions. How can I test your suggestion? (working without QCoreApplication).
I can't use QCoreApplication, because its't not allowed by usage scenarios.
I'm afraid that I need thread-safety in scenario, when mailing DLL will called by different applications at the same time. May be I need messages queue or something like that?@meteoir said in Does Qt-based dll can be used by another non qt-based app (without QApplication)?:
Yes, I'm using waitForConnected/waitForReadyRead/waitForBytesWritten/waitForEncrypted functions. How can I test your suggestion? (working without QCoreApplication).
How to test? Just try it in real applications. See if you can make it fail.
I know this is not a rigourous test, but that's because using these complex QObjects without QCoreApplication is not really tested in Qt itself.
I can't use QCoreApplication, because its't not allowed by usage scenarios.
I don't understand. Who doesn't allow it?
I'm afraid that I need thread-safety in scenario, when mailing DLL will called by different applications at the same time. May be I need messages queue or something like that?
Different applications run in different processes, which means each application loads its own copy of the DLL into memory. You don't have to worry about them sharing the same objects.
But if you want to write thread-safe code, then you can manage your own threads and locks.
-
Yes, I'm using waitForConnected/waitForReadyRead/waitForBytesWritten/waitForEncrypted functions. How can I test your suggestion? (working without QCoreApplication).
I can't use QCoreApplication, because its't not allowed by usage scenarios.
I'm afraid that I need thread-safety in scenario, when mailing DLL will called by different applications at the same time. May be I need messages queue or something like that?Hi @meteoir
I had a similar taks two years ago, and I also used the waitFor... functions in my DLL (without threads).
I had some problems with growing memory and therefore created QTBUG-53798.
I was able to solve this with a QCoreApplication instance and regular
QCoreApplication::processEvents()calls and since then the library is used without problems.Regards
-
Using of QCoreApplication is not allowed, because some applications, that uses DLL, are qt-based. And only one qcoreapplication must exists. Can I solve that problem?
@aha_1980 thx, but as I understand, if my DLL will be used in qt-based application, I can't instantiate QCoreApplication (DLL consumer already creates it). What I need to do in that case?
-
Using of QCoreApplication is not allowed, because some applications, that uses DLL, are qt-based. And only one qcoreapplication must exists. Can I solve that problem?
@aha_1980 thx, but as I understand, if my DLL will be used in qt-based application, I can't instantiate QCoreApplication (DLL consumer already creates it). What I need to do in that case?
@meteoir said in Does Qt-based dll can be used by another non qt-based app (without QApplication)?:
Using of QCoreApplication is not allowed, because some applications, that uses DLL, are qt-based. And only one qcoreapplication must exists. Can I solve that problem?
You can call
QCoreApplication::instance()to check if the app already has one. See https://doc.qt.io/qt-5/qcoreapplication.html#instanceIf the app already has one, then you don't have to do anything. If not, you can now create your own QCoreApplication.
Qt Doc Search for browsers: forum.qt.io/topic/35616/web-browser-extension-for-improved-doc-searches
-
@meteoir said in Does Qt-based dll can be used by another non qt-based app (without QApplication)?:
Using of QCoreApplication is not allowed, because some applications, that uses DLL, are qt-based. And only one qcoreapplication must exists. Can I solve that problem?
You can call
QCoreApplication::instance()to check if the app already has one. See https://doc.qt.io/qt-5/qcoreapplication.html#instanceIf the app already has one, then you don't have to do anything. If not, you can now create your own QCoreApplication.
@JKSH said in Does Qt-based dll can be used by another non qt-based app (without QApplication)?:
You can call QCoreApplication::instance() to check if the app already has one. See https://doc.qt.io/qt-5/qcoreapplication.html#instance
If the app already has one, then you don't have to do anything. If not, you can now create your own QCoreApplication.Exactly.
-
Ok, i'm copy that. But when I create an instance of QCoreApplication in my DLL, I need to call QCoreApplication::exec() for processing events etc. But calling this method will freeze my app (working continue only after exit).
Sending functions from DLL will called on worker thread only and I don't understand how can I proceed events and other parts of sockets comminucation.
waitFor* functions are synchronous, but I'm also can't understand how can I provide sending process notifications to DLL-user application? Data chunk sending needed in that case.
