Problems Connecting to QMainWindow::repaint()
-
@JonB said in Problems Connecting to QMainWindow::repaint():
But signals and slots are just as much "regular C++ overloaded functions" as any other C++ function
I know, because there is nothing such as "signals" in C++. Technically they are all functions interpreted together with the Qt macros by MOC/compiler.
Unless you say there is something really special about connect()/signal/slot, which I don't think there is. And compared to the rest of C++ I don't think there is that much extra typing you have to do... :)
I started this, mainly speaking of public Qt API (i.e. public Qt signals).
Therefore I thought of changing ambiguous signals (or "functions" which are used in signal/slot connections) in the first place...
Other functions you would never put in a situation like this, where this topic is all about.Connecting to functions, not declared as
public slotsbecame possible with the PMF/Functor syntax.
The old, string based style excluded most "critical" overloads.
(see, only the parameterlessupdate()andrepaint()functions are declared slots)
The string connection style requires to specify the signal's and slot's params, but since back then there was only one available for you (the empty call()) you had no choice anyway :)I got your point, hope you got mine ;-)
Edit:
At least you can get rid of every "signal" function overload without worrying about something else, as they have one purpose only: To be used in Qt's signal-slot connections.
That's what Qt did e.g. withQButtonGroupalready@Pl45m4 said in Problems Connecting to QMainWindow::repaint():
That's what Qt did e.g. with QButtonGroup already
Not only there, take a look at the deprecated stuff in 5.15 :)
Qt Online Installer direct download: https://download.qt.io/official_releases/online_installers/
Visit the Qt Academy at https://academy.qt.io/catalog -
I'd like to jump with some remarks to the OP's problems.
First of all, the connect should be properly written as
QObject::connect( pDoc, &MyDoc::RequestRedraw, this, &MainWindow::repaint );The only way I have learned the new connect syntax is to 1) take the address of the member function (hence the
&) and 2) use the fully qualified name with the class name in front of it. At least in the description you have written,QWidget::redrawis not the same asrepaint. Those are two different words with the same meaning.As already mentioned, if you are connecting to an overloaded function (doesn't matter if its a slot or not), you need to use the
qOverloadfunction with the specific type. On older compilers you had to use the long formQOverload::ofinstead.Also, don't call
repaintdirectly unless you really have to.updateis a lot more efficient because it will first collect several update calls and then issues a single repaint.One final comment: The string based connect syntax always compiles. It does not matter what you write inside the
SLOT(...)andSIGNAL(...)macros. Those will expand to strings and are not checked at compile time. This means even though it compiles it might not work. You need to watch out for debug messages when running your program that tell you that a signal or slot could not be found. Using the new syntax is more along the lines of "when it compiles it works", whereas the string based syntax is just a gamble. -
@Pl45m4 said in Problems Connecting to QMainWindow::repaint():
That's what Qt did e.g. with QButtonGroup already
Not only there, take a look at the deprecated stuff in 5.15 :)
@Christian-Ehrlicher said in Problems Connecting to QMainWindow::repaint():
Not only there, take a look at the deprecated stuff in 5.15 :)
Yeah, that's what my posts above were all about :))
I like the trend to move away from overloads, at least for public API signals... because as we can learn from the topic here, dealing with overloaded signals is a pain ;-)
If debugging is the process of removing software bugs, then programming must be the process of putting them in.
~E. W. Dijkstra
-
@Christian-Ehrlicher said in Problems Connecting to QMainWindow::repaint():
Not only there, take a look at the deprecated stuff in 5.15 :)
Yeah, that's what my posts above were all about :))
I like the trend to move away from overloads, at least for public API signals... because as we can learn from the topic here, dealing with overloaded signals is a pain ;-)@Pl45m4
My last personal observation. Overloads are so easily coded, I always:- Stick in without
qOverload()and see if compiler/code model tells you overload needed. 99% not, 1%... - ...Look up desired overload in docs and put into
qOverload<>(). If compiler did not complain it would be harder, but it does....
#2 takes a few seconds. So I don't get the problem.
- Stick in without
