Problems Connecting to QMainWindow::repaint()

Christian Ehrlicher

@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 :)

SimonSchroeder

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::redraw is not the same as repaint. 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 qOverload function with the specific type. On older compilers you had to use the long form QOverload::of instead.

Also, don't call repaint directly unless you really have to. update is 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(...) and SIGNAL(...) 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

@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 ;-)

JonB

@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.