Problems Connecting to QMainWindow::repaint()

[Calvin H-C]

I am having an issue using QObject::connect() to connect a signal in an object of mine that inherits QObject that needs to have my main window derived object redraw.

Here is the partial (related to the signal, for brevity) declaration of my object:

class MyDoc : public QObject
{
    Q_OBJECT
signals:
    void    RequestRedraw();
};

My main window object is declared with the following (other details not relating to this issue removed for brevity):

class MainWindow : public QMainWindow
{
    Q_OBJECT
};

I thought I could connect the signal in MyDoc to the redraw slot using this call in a member function of my main window object ("pDoc" is a pointer to the MyDoc object):

QObject::connect( pDoc, &( pDoc->RequestRedraw ), this, &repaint );

The error this generates says:

no matching function for call to 'MainWindow::connect(MyDoc*&, void (MyDoc::)(), MainWindow, <unresolved overloaded function type>)'

My first thought was that I needed to be more specific about "redraw", so I thought I should change it to "QWidget::redraw", but the same error occurred.

I understand that there are four overloads for repaint(), but shouldn't it choose the one with no parameters because the signal (MyDoc::RequestRedraw()) has no parameters. It seems that I need to tell it explicitly to use that overload, but I'm not sure of the syntax.

To test this theory, I created a slot in my main window class that looks like this:

void MainWindow::OnUpdateNeeded()
{
    repaint();
}

It all works fine when I connect it with this:

QObject::connect( pDoc, &( pDoc->RequestRedraw ), this, &OnUpdateNeeded);

So, what is the correct syntax to connect directly to the correct overload of QWidget::redraw() without going through a "wrapper" function?

[Calvin H-C]

I have found that using the SIGNAL() and SLOT() macros solves the error:

QObject::connect( pDoc, SIGNAL( pDoc->RequestRedraw() ), this, SLOT( repaint() ) );

The documentation says that the macros should be used, but I've seen a number of examples where they are not and everything works fine. I'm wondering why this matters in this case while it doesn't in others.

[Pl45m4]

@Calvin-H-C said in Problems Connecting to QMainWindow::repaint():

So, what is the correct syntax to connect directly to the correct overload of QWidget::redraw() without going through a "wrapper" function?

Use a lambda expression or, although I never thought I'd ever recommend using the string connection style, here it works, as only the repaint() is a declared Qt Slot... the other ones are regular functions (and also work but only in a Functor based connection)

Anyway, it would be safer/better to call update() on your widget instead of repaint() directly...
However for some reason invoking update through a signal, it somehow also "finds" the wrong one...

Tested myself:

connect(pb, &QPushButton::clicked, this, &MainWindow::update);

leads me to:

inline void QWidget::update(int ax, int ay, int aw, int ah)
{ update(QRect(ax, ay, aw, ah)); }

which is obviously a mismatch...

I could swear, I'ved used the above code dozens of times
(because update() slot exists and clicked has default argument for checkable buttons)

Edit:

Oh, you figured it out already

@Calvin-H-C said in Problems Connecting to QMainWindow::repaint():

The documentation says that the macros should be used, but I've seen a number of examples where they are not and everything works fine. I'm wondering why this matters in this case while it doesn't in others.

Usually you should really avoid the String-based style nowadays, but in some edge cases the string-based syntax works where functors do not...
The string-based style is also used quite often in Qt internally
See my topic and @Christian-Ehrlicher 's reply here

Edit_2:

I guess we have to wait until somebody who knows what's going on is commenting on this :)

Also not working anymore, which definitely used to work.

    QTimer *timer = new QTimer(this);
    timer->setInterval(1000);
    // crashes due to mismatch  "<unresolved overloaded function type>"
    connect(timer, &QTimer::timeout, this, &MainWindow::update);

Qt 6.7, Windows 10

[jsulm]

@Calvin-H-C The error message tells you that repaint() is overloaded, so there is more than one version of it and connect() does not know which one you want to connect. See https://wiki.qt.io/New_Signal_Slot_Syntax#Overload how to tell which overloaded version you want to use.

[Pl45m4]

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

Also not working anymore, which definitely used to work.

QTimer *timer = new QTimer(this);
timer->setInterval(1000);
// crashes due to mismatch  "<unresolved overloaded function type>"
connect(timer, &QTimer::timeout, this, &MainWindow::update);

@jsulm what about this?!
I could swear I have used code like this in the past without issues and there are hundreds of examples out there, showing code like this (I know, you cannot trust these random code snippets)... but I was actually surprised that this connection with PMF doesn't work (anymore?!).
In fact there ARE matching signals and slots available.

and I've never used qOverload<>::(&QWidget::update) or something before

[Christian Ehrlicher]

@Pl45m4 update() always had those overloads so it should never work.

[Pl45m4]

@Christian-Ehrlicher

Mh, strange.

There are so many topics here in the forum, on StackOverflow and everywhere else...
Nobody complained that the posted solutions is wrong or does not work

Like here

Maybe they also converted the String syntax to PMF/Functor-based style and never tested or reported back the issues that they are having... :)

[JonB]

@Pl45m4
FWIW, I'm surprised you say you have never had to use qOverload/QOverload::of (introduced around Qt 5.7, and before then you had to use a static_cast<> thing) where there are indeed multiple overload signatures. I have never used SIGNAL/SLOT(), always PMF, and have had to use qOverload from the start whenever there was ambiguity, including e.g. update(). Qt docs have some examples for connect(), e.g. https://doc.qt.io/qt-5/qspinbox.html#valueChanged. Even PySide/PyQt have a funny syntax for achieving the same as qOverload. Go find an example in your old code where you have really gotten away without it! ;-)

[Pl45m4]

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

FWIW, I'm surprised you say you have never had to use qOverload/QOverload::of (introduced around Qt 5.7) where there are indeed multiple overload signatures.

I didn't say "never", I said

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

I've never used qOverload<>::(&QWidget::update) or something before

I've used overload for overloaded signals (for example for QSpinBox::valueChanged, as you also mention)...
but never for overloaded functions/slots like update() or repaint() :)

I could still swear this worked to some point.... well... I don't know. Apparently it does not and never did (unless you are using the string style)

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

Go find an example in your old code where you have really gotten away without it! ;-)

Don't have code of mine at hand right now, but just google...
Dozens of examples and code snippets here in the forum and on StackOverflow...
and nobody claimed that it's not working... even in "accepted" solutions/answers.

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

@Christian-Ehrlicher

Mh, strange.

There are so many topics here in the forum, on StackOverflow and everywhere else...
Nobody complained that the posted solutions is wrong or does not work

Like here

Maybe they also converted the String syntax to PMF/Functor-based style and never tested or reported back the issues that they are having... :)

[JonB]

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

I've used overload for overloaded signals (for example for QSpinBox::valueChanged, as you also mention)...
but never for overloaded functions/slots like update() or repaint() :)

Ah, I had not appreciated you were commenting on need for overload on slots rather than signals. I had a search of all my old code (amazing what grep -r --include=... can achieve!) and although using it on signals is more frequent I did find myself using it on slots too, though they were my own rather than Qt inbuilt ones.

[Pl45m4]

@JonB

Fortunately the trend is moving away from ambiguous signals/functions with different parameters...
They've changed it in some of the public API already...
Also, IIRC, clang/clazy recommends not to do it, when you try to overload your own, custom Qt signal.
It advises to slightly change the naming and include the "signature" in the name of the signal, like Qt did in Qt6 (don't know in what release it started) for QButtonGroup (and probably many more):

• https://doc.qt.io/qt-6/qbuttongroup.html#signals (Qt6)
  vs.
• https://dreamswork.github.io/qt4/classQButtonGroup.html (Qt4.8)

So instead of one generic signal with multiple overloads for various use cases

• void buttonClicked (QAbstractButton *)
• void buttonClicked (int)

they changed to:

• void buttonClicked (QAbstractButton *)
• void idClicked(int id)

I like it and this makes totally sense ;-)
A signal called <type>changed/clicked/whatever(<type> t) transmits parameters with type <type>.
Better in every aspect than widgetChanged/clicked/whatever(<some_type> t) and then you have to figure out through a list of overloads what overload/type you need or want to address :)

AFAIK the overloads were tolerated in whole Qt5 and became deprecated with Qt6.

[JonB]

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

Also not working anymore, which definitely used to work.

I rolled out my decommissioned Ubuntu 22.04, Qt 5.1.5, gcc 11.4 and copy-pasted your connect(timer, &QTimer::timeout, this, &MainWindow::update);. It does fail with same "unresolved overloaded function type" error as under Qt 6, so dunno when it used to work for you... :)

[Pl45m4]

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

It does fail with same "unresolved overloaded function type" error as under Qt 6, so dunno when it used to work for you... :)

Ok, ok you won :D

but that doesn't change the fact that overload sucks :D

[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!