Registering C++ objects in QML
-
Actually the "best" singleton is one that you don't create. When I need the global scope I usually do what
QCoreApplicationdoes:class MyGlobalClass : public QObject { static MyGlobalClass * p; public: inline MyGlobalClass(QObject * parent) : QObject(parent) { Q_ASSERT(!p); p = this; } ~MyGlobalClass() override { p = nullptr; ] inline static MyGlobalClass * instance() { // Q_ASSERT(p); can be added optionally. return p; } }; MyGlobalClass * MyGlobalClass::p = nullptr;and I create it where it's supposed to go - in the stack (somewhere):
int main(int argc, char ** argv) { QCoreApplication app; MyGlobalClass theObject(&app); // ... return ... }I continue to claim that a "singleton" is nothing more than a glorified global variable, so it should be treated exactly as such - a
badmonstrously stupid idea in 99.999% of cases! -
This post is deleted!
@stehlo said in Emiting signals from singletons:
This is an inappropriate statement because I have specifically mentioned that I arrived at the fix after an extensive testing session. I have most definitely not jumped to any conclusions out of the blue.
It is a correct statement since, as @Chris-Kawa already mentioned a correct way to clean up stuff before the application ends and it works correctly. So the problem must be on your side but since you don't provide code we can't help.
-
Deleting the topic for sure helps to fix the problems...
-
Deleting the topic for sure helps to fix the problems...
-
This post is deleted!
@stehlo said in Emiting signals from singletons:
How do you use such a construct as an object in QML?
As a context property?
-
This post is deleted!
@stehlo It is your right to use the support that fits you best.
But once you asked in public, and many people tried to help you, these answers should stay public.
So I've restored the post, and I ask to to keep it that way. Thanks!
-
@stehlo It is your right to use the support that fits you best.
But once you asked in public, and many people tried to help you, these answers should stay public.
So I've restored the post, and I ask to to keep it that way. Thanks!
-
This post is deleted!
@stehlo said in Registering C++ objects in QML:
Therefore, I insist on the removal of this tainted topic without any further discussions.
It'd been forked in its own topic. Which should satisfy your request, shouldn't it?
-
Wow this escalated quickly!
I think the fork is a good idea, tbh.
@kshegunov said in Registering C++ objects in QML:
I continue to claim that a "singleton" is nothing more than a glorified global variable, so it should be treated exactly as such - a bad monstrously stupid idea in 99.999% of cases!
sadly, in combination with QML your options are limited. If you want to access the class from cpp and QML you can do one of the following
- Singleton, instance in cpp and exactly where you need it in qml
- Normal instance in cpp, a global property accessible in all qml files
- using find child to search for your qml item and do the connect in cpp. This falls apart as soon as you start to dynamically load your qml files
So, Pest Cholera, or Malaria.
@stehlo said in Registering C++ objects in QML:
Without going into extra detail which would detract from the main point, the attempt to deleteLater the QObject unnaturally at the point of the application being aboutToQuit causes either of the two following fatal errors, depending on whether we do this for the networking singleton or the database one:
QObject: shared QObject was deleted directly. The program is malformed and may crash.
abort_message: assertion "Pure virtual function called!" failed
Fatal signal 6 (SIGABRT), Abortedor
null pointer dereference
Fatal signal 11 (SIGSEGV), Segmentation faultThe attempt to deleteLater is happening either too early or two late.
I actually have to disagree.
after reading the post by @Chris-Kawa I changed my own project to include the about to quit cleanup. That's for about 10 Singletons not once did I have one of your errors mentions above.I would say there's still something going on that causes your issue, but I think it's user -rather than framework related
Be aware of the Qt Code of Conduct, when posting : https://forum.qt.io/topic/113070/qt-code-of-conduct
Q: What's that?
A: It's blue light.
Q: What does it do?
A: It turns blue. -
Wow this escalated quickly!
I think the fork is a good idea, tbh.
@kshegunov said in Registering C++ objects in QML:
I continue to claim that a "singleton" is nothing more than a glorified global variable, so it should be treated exactly as such - a bad monstrously stupid idea in 99.999% of cases!
sadly, in combination with QML your options are limited. If you want to access the class from cpp and QML you can do one of the following
- Singleton, instance in cpp and exactly where you need it in qml
- Normal instance in cpp, a global property accessible in all qml files
- using find child to search for your qml item and do the connect in cpp. This falls apart as soon as you start to dynamically load your qml files
So, Pest Cholera, or Malaria.
@stehlo said in Registering C++ objects in QML:
Without going into extra detail which would detract from the main point, the attempt to deleteLater the QObject unnaturally at the point of the application being aboutToQuit causes either of the two following fatal errors, depending on whether we do this for the networking singleton or the database one:
QObject: shared QObject was deleted directly. The program is malformed and may crash.
abort_message: assertion "Pure virtual function called!" failed
Fatal signal 6 (SIGABRT), Abortedor
null pointer dereference
Fatal signal 11 (SIGSEGV), Segmentation faultThe attempt to deleteLater is happening either too early or two late.
I actually have to disagree.
after reading the post by @Chris-Kawa I changed my own project to include the about to quit cleanup. That's for about 10 Singletons not once did I have one of your errors mentions above.I would say there's still something going on that causes your issue, but I think it's user -rather than framework related
@j-hilk said in Registering C++ objects in QML:
Normal instance in cpp, a global property accessible in all qml files
What I wrote. Normal object in C++, a context property in QML. Which is kind of the point of having context properties to begin with, is it not?
Read and abide by the Qt Code of Conduct
-
@j-hilk said in Registering C++ objects in QML:
Normal instance in cpp, a global property accessible in all qml files
What I wrote. Normal object in C++, a context property in QML. Which is kind of the point of having context properties to begin with, is it not?
@kshegunov yes, and also the reason why I think the Singleton is the lesser of 2 evils, as it's not globally accessible in all Files but has to be explicitly imported inside the File.
Wouldn't you agree 😉
