Unsolved One signal, multiple slots
-
Hi,
I have a text edit that emits textChanged signal, which I use to change the color of text if it was modified. But I also want to validate the input.
Should I create another slot for the same signal textChanged? Or combine the code for changing the color and validation in one slot?
-
-
I will check QValidator but which is the better approach.
- one signal, all unrelated code in one slot (in my case, changing color + validation)
- one signal, multiple slots
Put my problem aside, which is better design?
-
@WhatIf
Don't take this the wrong way, but the question sounds like: "Which is better apples or oranges?". Well, it depends.On the one hand it depends on the semantics - is the color change independent of the data validation, that is: will the color be different if data is changed no matter the data may be invalid? If the answer is yes, then that suggests two slots connected to a single signal.
On the two hand, it's also a matter of taste.Kind regards.
-
@WhatIf said:
I will check QValidator but which is the better approach.
- one signal, all unrelated code in one slot (in my case, changing color + validation)
- one signal, multiple slots
Put my problem aside, which is better design?
Another option is to have one slot, let's call it "reactOnTextChanged", which in turn calls the separate methods. Makes the code easy to read, too. You see exactly what "reactOnTextChanges" does if the methods it calls are well-named.
-
One last question, is the order of calling the slots guaranteed?
For example, if the first connect calls changeColor() and the second connect calls validate(). Am I guaranteed to have changecolor() slot called and complete first before validate() slot is called?
I'm asking because the behavior I'm getting it's as if mid-way through the first slot, the second slot begins to execute.
Would greatly appreciate your clarification!
-
is the order of calling the slots guaranteed?
When the connection is inside a single thread (
Qt::AutoConnection
is equal toQt::DirectConnection
) then yes, the order of slot invocations is in the order the connects were made. Order is undefined when the connections are across threads. However, bear in mind that the order of the slots is an implementation detail and you shouldn't depend on it.For example, if the first connect calls changeColor() and the second connect calls validate(). Am I guaranteed to have changecolor() slot called and complete first before validate() slot is called?
Yes, if you're connecting objects with the same thread affinity ("living" in the same thread).
I'm asking because the behavior I'm getting it's as if mid-way through the first slot, the second slot begins to execute.
The only way this may happen is if you have the slots executed directly from two different threads, in all other cases the slots' execution is serialized.
Kind regards.
-
@WhatIf said:
I'm asking because the behavior I'm getting it's as if mid-way through the first slot, the second slot begins to execute.
Have you checked the call stack? It is possible that the 1st slot makes some change that causes the related signals to fire again. That would explain it.