2nd GUI signals not delivered
-
Hi
I have a gui that has lineEdit_textEdited signal'
The gui may be called 1..4 times
The first time (gui1, gui2, gui3 ..) works perfectly
The next time THAT signal is not delivered.
The 2 GUI are totally independent except for DBUS
I can see each getting the other DBUS signals.
WHERE can I start to debug
Thanks
James -
Hi
I have a gui that has lineEdit_textEdited signal'
The gui may be called 1..4 times
The first time (gui1, gui2, gui3 ..) works perfectly
The next time THAT signal is not delivered.
The 2 GUI are totally independent except for DBUS
I can see each getting the other DBUS signals.
WHERE can I start to debug
Thanks
James -
I'm happy to post code, but there are 10 000 lines :-(
What I did, without changing source in any way was build on ubuntu 22.04 where everything worked as expected. I then re-installed openSuSE leap 15.4 and now everything works as expected.
Somewhere Somehow knickers in a knot. Happy, but a trifle confused, I emphasize my confusionGUI1 everything worked
GUI2 everything worked
GUI1 then GUI2 : GUI2 fails
GUI2 then GUI1: GUI1 failsGUI1 and GUI2 are totally independent (with different args) except both share DBUS
DBUS messages are sent and received by both.
Impossible hence my confusion, but thanks
James -
I'm happy to post code, but there are 10 000 lines :-(
What I did, without changing source in any way was build on ubuntu 22.04 where everything worked as expected. I then re-installed openSuSE leap 15.4 and now everything works as expected.
Somewhere Somehow knickers in a knot. Happy, but a trifle confused, I emphasize my confusionGUI1 everything worked
GUI2 everything worked
GUI1 then GUI2 : GUI2 fails
GUI2 then GUI1: GUI1 failsGUI1 and GUI2 are totally independent (with different args) except both share DBUS
DBUS messages are sent and received by both.
Impossible hence my confusion, but thanks
James@jamat13 said in 2nd GUI signals not delivered:
I'm happy to post code, but there are 10 000 lines :-(
If you don't spend your own time to narrow this down and produce a minimal example, from your description you expect someone to say what the issue is, and why it works under one Linux and not another?
-
No but I was casting about in case anyone had seen similar. Since all is now working it'd be impossible to condense down. Since each (unix) process is isolated there is no other explanation than moc's magic somehow went awry. If I never see the issue again well-n-good else time for some serious spelunking
-
No but I was casting about in case anyone had seen similar. Since all is now working it'd be impossible to condense down. Since each (unix) process is isolated there is no other explanation than moc's magic somehow went awry. If I never see the issue again well-n-good else time for some serious spelunking
@jamat13 said in 2nd GUI signals not delivered:
moc's magic somehow went awry.
That is a surprising conclusion. Since moc acts only at compile time and produces C++ code which you can inspect. Anyway if you can't reproduce anything there is not much to analyze. Random possibilities could include uninitialized variables or other code fault or incorrect use of threads if you use them.
