@SpaceToon said in Is it possible to receive a signal from a class that was instantiated twice?:

int main(int argc, char *argv[])
{
QApplication a(argc, argv);
MainWindowA m;
m.show();
return a.exec();
}

Where is your MainWindowB instance create? Does MainWindowA do this somewhere?

In general, I would expect something along these lines in main:

int main(int argc, char *argv[]) { QApplication a(argc, argv); emitSignalClass emitter; MainWindowA mA(&emitter); mA.show(); MainWindowB mB(&emitter); mB.hide(); return a.exec(); }

Create an instance of your signal-emitting class first and hand it to the constructurs. Store a pointer to the same emitter object as member variable in both MainWindowA and MainWindowB.

@LeLev
Ok - looks like I need to follow that up

@jsulm They are created inside main.cpp. Usage is high as pretty much every calculation is done in 'em.

@J-Hilk They are currently registered via setContextProperty and can hence be used freely throughout our QML code but not the Qt/C++ part.

@SGaist Thank you, but this is actually the class where I am creating the tables when database is empty and holding all the models and necessary functions to work on them. So it is fine in this case :)

I know this answer is a bit late, but one solution that comes to my mind is to separate UI from logic. Create one file (e.g. a ui.qml file) for your UI and use it in another qml file.

@eggbertx said in Trying to create a singleton and getting LNK2019 error:

Sorry, I meant the second code block, not the first. I'm not very familiar with assertions in general, so I've never heard of Q_ASSERT.

The assertion here is only a tool to detect creating more than one instance of the class. Q_ASSERT is a Qt macro for regular debug assertions, it will be removed in release mode, so its purpose (as assertions in general) is to catch programmer errors while debugging. So if you use the class above like this:

Singleton object1; Singleton object2; //< Here the assertion will be tripped and you can catch the error while debugging

Adding the code in the second block fixed the issue.

Do you mean the main window constructor where the connect is made? All code blocks are part of one single example, so I'd expect them to work together only. :)

I appreciate your response, it lead me to a lot of research on the topic! I figured out it was much easier to implement a tabview on the main view and then to connect the signals with the child objects which were themselves individual views.

@Stefan-Monov76 you could also use something like that:

class FileIO: public QObject{ Q_OBJECT public: //singleton type provider function for Qt Quick static QObject* fileIOSingletonTypeProvider(QQmlEngine *engine, QJSEngine *scriptEngine); //singleton object provider for C++ static FileIO* instance(); void myFancyFunction(); }; QObject* FileIO::fileIOSingletonTypeProvider(QQmlEngine *engine, QJSEngine *scriptEngine){ Q_UNUSED(engine) Q_UNUSED(scriptEngine) return FileIO::instance(); } FileIO* FileIO::instance() { static FileIO* fileIO = new FileIO(); return fileIO; } void FileIO::myFancyFunction(){ //do something }

In that case you could get the singleton, with:

FileIO::instance()->myFancyFunction();

Thanks, it work !