Problems Connecting to QMainWindow::repaint()

JonB

@Pl45m4
I didn't mean to point-score, I was just interested, honest!

It advises to slightly change the naming and include the "signature" in the name of the signal

Well I don't see much difference between signals, slots and any other method. So if we're going to give up on same-name-methods-with-parameter-overloading and go for different-name-with-indicator-of-which-one-it-is-for we can give up on C++ and go back to C where this used to be a thing, and not a bad idea that would be ;-)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

I didn't mean to point-score

I didn't felt like you did :) All good.

Well I don't see much difference between signals, slots and any other method. So if we're going to give up on same-name-methods-with-parameter-overloading and go for different-name-with-indicator-of-which-one-it-is-for we can give up on C++ and go back to C where this used to be a thing, and not a bad idea that would be ;-)

In my eyes, there is nothing wrong with that. Re-using C-related things in C++ is not always a bad idea ;-)
(C-casts might be :P )

You don't have to overshoot and change the way you name things in general, but anything is better than this clunky overload connection syntax...
When you already know that your signal/slot/function needs to take like three, four different arguments, which probably would have different effects (passing an int might be very different from passing a struct or string somewhere, even when it's for the same reason = same "function"), I think you should write separate functions anyway.

Also anyone can see right away what's going on

sendText(output)
is more meaningful than
send(output)
where you have to figure it out first, because output could be an int, a string, some struct... anything...

Imagine using overloads of the signal AND slot... your connection becomes twice as long and harder to read.

When multiple Foo::fooSignal and Bar::barSlot exist:

connect(foo, qOverload<FooType>::(&Foo::fooSignal), bar, qOverload<FooType>::(&Bar::barSlot));
connect(foo, QOverload<FooType>::of(&Foo::fooSignal), bar, QOverload<FooType>::of(&Bar::barSlot));

Urgh. :D

So I would prefer

void idClicked(int id)

over an overload of

void buttonClicked (QAbstractButton *)
void buttonClicked (int)

any time.

JonB

@Pl45m4
Well we're entitled to our own opinions, but I rather like the ability to overload same method name instead of invent different names for each one. What are you going to name e.g. each of the QObject::connect() methods? And overloading applies to constructor calls too, right, else there are a lot to write for QVariant(...) :)

Pl45m4

@JonB said in Problems Connecting to QMainWindow::repaint():

What are you going to name e.g. each of the QObject::connect() methods?

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

You don't have to overshoot

;-)

I mainly thought about the case when designing your public API in your application with Qt (with public signals/slot/functions etc.) and not to re-write every overloaded function which is existing ;-)
QObject::connect(...) ifself is not used in connections :)

And for regular C++ overloaded functions you don't have to specific anything. What is picked is decided by parameters and name.

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

void buttonClicked (QAbstractButton *)
void buttonClicked (int)

This just makes life harder as it should be :)

JonB

@Pl45m4 said in Problems Connecting to QMainWindow::repaint():

And for regular C++ overloaded functions you don't have to specific anything.

But signals and slots are just as much "regular C++ overloaded functions" as any other C++ function. It's just that you don't so often need to specify C++ functions as parameters to another function, like connect(), so you don't happen to notice the need to specify which overload so much. But you would if you did. 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... :)

Pl45m4

@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 slots became possible with the PMF/Functor syntax.
The old, string based style excluded most "critical" overloads.
(see, only the parameterless update() and repaint() 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. with QButtonGroup already

JonB

@Pl45m4
Yeah, we're all good :)

C++ '56 will prolly change all this...

I only just realised you are not the OP of this thread, I thought you were, hope we haven't hijacked it from OP!

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.