@Redman cool 😎

@papisant Well, I'm not sure why it did not work with your original m_mediaDevices{std::make_shared<QMediaDevices>(this) which would surely be a class member too. Anyway, the important take away from this is: when connecting a signal you must look at the scope/lifetime of the signalling object (same for the slot). If either of these is a "local variable" that means the object will go out of scope and be destroyed at the end of the function they are in. And when Qt sees either the signalling or slot object being destroyed it auto-disconnects any connected signals/slots for that object (for obvious reasons). A connection only persists as long as both signal & slot objects are in existence. That is why class members are often used, or the object must be newed and not deleted.

Hi @dheerendra I think the issue was in NO_PLUGIN as were suggested by @Anumas here: https://forum.qt.io/post/802964 Seems to be working fine with static library now. I marked that message as a solution.

Hey @eternal_void , I just got back to using Qt for another project. This is new account (I was @talksik), but here are my findings in a similar post after a ton of research and coming up with a custom solution not really mentioned anywhere: https://forum.qt.io/post/821291

@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 !