When does an emit start the method to service it?
I have a state machine (switch statement) that is controlled by pressing Qt buttons. When a button in pressed it executes the method containing the state machine. Once in a while there may be reason to skip a state because there is only one option (i.e. there isn't a reason to ask the user as the answer is obvious). So I was trying to skip over these "silly" questions by simulating a button press by using the emit command. I thought button presses and emits would lock each other out. That is, I assumed I could not call my state machine recursively. But I have been seeing some funny stuff. So now I am wondering if my assumption is true.
If I am managing to recursively enter my state machine, how would I get around this problem? Set a flag and use an external timer to run the emit? Sounds very Rube Goldberg-ish.
Unless you are using queued connections, an emit immediately executes all of the slots connected to that particular signal.
Without seeing a sample of your code, it's hard to determine what's happening. What, exactly, are you emitting?
did you tried to call the slot directly instead of find the button object and 'force' a signal just to call the slot?
Sounds like your program is actually in a different state in that case. That would mean you have to actually document that state (and its transitions) in your code.
Slots can be executed immideatly or queued, depending on the connection and the thread appearance.
By default, connections are auto connections, which means, if the objects live in the same thread, they are direct connections. direct connections are like direct function calls. If the objects live in different threads or you specify QueuedConnection in the connect statement, the signal is queued to the event queue and executed in the next queue iteration (message Loop).
To specify a connect type, use the following connect statement:
connect (sender, signal, receiver, method, Qt::QueuedConnection);