@moellney said: Anyway, my intention for this discussion was not to start a discussion about pro/contra of exceptions, though. Yup, sorry. One of the downsides of exceptions is it's almost impossible to talk about them without talking about whether they're worth it. My question was more, if there is an established design concept Well, as the link you originally posted says - exceptions thrown across connections are undefined behavior. This in practice means that anything that can be used in a Qt connection should not throw exceptions. This means any method of a QObject derived class, any free standing function, lambda or functor you intend to use in a connection. So yes, you should mark all of that noexcept and generally the more localized your exception handling is the better/safer. As for threading - exception handling is only supported by QtConcurrent and QException derived exception types. Anything else is unspecified, so basically a no-no. If you build models/backend around exceptions don't just keep them local and make sure you catch them before crossing into the Qt land. I'm still looking into details about the STL Yeah, this is one of the reasons I wish noexcept had different defaults :( Implementations like this make things slow by default, which is very sad for C++.

@mrjj Thank you, thank you, thank you. It is always a pleasure to work with someone who knows their stuff. I had overlooked the step of connecting FortuneServer's signal to Dialog's slot in the dialog. I added in dialog.cpp: connect(&server, SIGNAL(connectionMade(QString)), this, SLOT(setConnectionText(QString)) ); Once I put this in, it worked like a champ! Marking it solved. Thanks again.

@J.Hilk I found out what my problem was. My two slot are excuted. The problem was that it didn't pass a certain condition in the second slot. My problem is solved. Thank you for your responses. Best Regards,

@gizalp said in Qt Signal Slot: @mostefa Thanks, that fixed my problem! You are welcome =)

Isn't this the same issue as here https://forum.qt.io/topic/75821/qabstractsocket-unknownsocketerror-provides-errorstring-of-unknownerror?

Thanks for the quick reply guys! This should answer my questions. Also to be more specific, this is part of a setup/initialization-code so this objects and connections are created once during startup, so I should not flood the memory. The main loop of widgets is about 10 in size. But I see your point about the switch statement, I could wrap everything up in one connect-statement, but than I would have to create the 3 different Icons berforehand, to refer them correctly in the lambda. I may do that, was never a fan of switches in loops myself either. Anyway thanks alot. Greetings!

Thank you.

hi " When a signal is emitted, the slots connected to it are usually executed immediately, just like a normal function call. When this happens, the signals and slots mechanism is totally independent of any GUI event loop. Execution of the code following the emit statement will occur once all slots have returned. The situation is slightly different when using queued connections; in such a case, the code following the emit keyword will continue immediately, and the slots will be executed later." http://doc.qt.io/qt-5.5/signalsandslots.html

Both your classes need to inherit from QObject for the signal/slot mechanism to work. Code blocks are either preceded by 4 spaces (good for one liners): int variable; or they can be enclosed by `` ` (triple back ticks, good for inline elements and longer blocks): #include <iostream> int main (int argc, char * argv[]) { std::cout << "Hello, World!\n"; } Google Markdown syntax for some more markup details.

Hi, it is my bad...mrjj was right, I did an incorrect test. The object is not copyable...I have to make it copyable first..that is the reason why I see the issue probably. Thanks