QLabel signals, linkActivated and linkHovered

[SPlatten]

@Bonnie , please add:

connect(label, &QLabel::linkActivated, this, &MainWindow::label_linkActivated);

Just because I have that too, your version of Qt is also quite a lot older than I'm using...apart from that there is no difference.

[Bonnie]

@SPlatten
Fine, I've updated the testing code in the above.
But the output is still the same.
My current project started from 5.12, so I have only 5.12 installed.

[SPlatten]

@Bonnie , ok, thanks, so its only the version that is different. Shouldn't be to hard for anyone with the latest version to try.

[SPlatten]

@J-Hilk , I've tried:

cnSignal = QObject::connect(this, &clsQtLabel::enterEvent
                           ,this, &clsQtLabel::rptrEnterEvent);

clsQtLabel is the name of my derived class. The slot:

void clsQtLabel::rptrEnterEvent(QEvent* pEvent) {
    const QString cstrSignal("enterEvent");
    QJsonObject objJSON;
    if ( mpobjNode->blnCheckSubscribers(cstrSignal, &objJSON) == true ) {
        QJsonObject objParam;
        //objParam["event"] = strLink;
        objJSON[clsXMLnode::mscszAttrParameters] = objParam;
        emit mpobjNode->commonRptdSignal(objJSON);
    }
}

Something is wrong because the connect returns null and does not connect. This is from:

```

QMetaObject::Connection clsQtLabel::connect(clsSignal* pobjSignal) {
QMetaObject::Connection cnSignal;
if ( pobjSignal == nullptr ) {
//Cannot proceed without signal or subscriber, abort!
return cnSignal;
}
QString strSignal = pobjSignal->strGetSignal();
if ( strSignal.compare(clsQtLabel::mscszQtSignalEnterEvent) == 0 ) {
cnSignal = QObject::connect(this, &clsQtLabel::enterEvent
,this, &clsQtLabel::rptrEnterEvent);
} else if ( strSignal.compare(clsQtLabel::mscszQtSignalLinkActivated) == 0 ) {
cnSignal = QObject::connect(this, &clsQtLabel::linkActivated
,this, &clsQtLabel::rptrLinkActivated);
} else if ( strSignal.compare(clsQtLabel::mscszQtSignalLinkHovered) == 0 ) {
cnSignal = QObject::connect(this, &clsQtLabel::linkHovered
,this, &clsQtLabel::rptrLinkHovered);
}
return cnSignal;
}

[J.Hilk]

@SPlatten enterEvent is not a signal but a function. it gets called automatically and you're supposed to override it!

[mrjj]

@SPlatten
Hi
enter and leave events are virtual functions and not signals.
hehe ninjaed by @J-Hilk :)

[SPlatten]

@mrjj , bugger, why why why?

[mrjj]

@SPlatten
That is just normal OOP.
Also, one can subclass and emit a signal in those event handlers to have it as signals also.
But default its not signals :)

[SPlatten]

@mrjj , what I meant was why do it a different way when signals and slots are used for so much of everything else already?

[mrjj]

@SPlatten
well one reason is that signal and slot cannot return values as such.
So it wont be useful for normal OOP where you overwrite virtual functions to alter logic.
Its not easy to do with signals alone. Also very, very often you want to call base class version of the function you overrride as you only want to extend it and keep old logic too and in this case a signal system would be very clunky.

btw. in your use case if you want hover events but dont feel like subclassing. you could use eventfilter and cheat that way.

[SPlatten]

@mrjj , thanks, I'm no newb when it comes to coding, but in this case I fail to see why enterEvent couldn't be a signal, its perfect for it.

[mrjj]

@SPlatten
Well often its used for hover effect and used internally by same Widget so im not sure
its a universal use case.
But good news is that you can make them signals :)
If you want.

[SPlatten]

@mrjj , this is my implementation:

void clsQtLabel::enterEvent(QEvent* pEvent) {
    QString strLink;
    if ( pEvent->type() == QEvent::Enter ) {
        strLink = text();
        emit linkHovered(strLink);
    } else if ( pEvent->type() == QEvent::Leave ) {
        emit linkHovered(strLink);
    }
}

Now I still have my connect code in place for:

cnSignal = QObject::connect(this, &clsQtLabel::linkHovered
                           ,this, &clsQtLabel::rptrLinkHovered);

It still doesn't get into my slot.

[mrjj]

@SPlatten said in QLabel signals, linkActivated and linkHovered:

emit linkHovered(strLink);

does it execute this line?

[SPlatten]

@mrjj Yes, verified in debugger.

[mrjj]

@SPlatten
maybe its due to reusing the signal. not sure.
Does connect return valid ?

[SPlatten]

@mrjj , resolved now, I was just in to much of a hurry and making silly mistakes.

[mrjj]

@SPlatten
we all been there , done that :)

[SPlatten]

Now thats fixed, more testing and with the same label which has been set-up as link to the Google website by setting the text to:

%3ca href%3d%22http://google.com%22%3eGoogle%3c/a%3e

and calling the function:

setOpenExternalLinks

I'm connecting the signals:

linkActivated and linkHovered

I've verified that the connection to each is successful by examining the return from the connect calls. The linkHovered now works perfectly, but I'm not getting the linkActivated when I click on the link, I have a breakpoint in the slot and it never gets there, the browser is launched correctly with the Google web-site.

I found this:
https://stackoverflow.com/questions/16581425/insert-clickable-link-in-qlabel-and-detect-click-on-this-link-to-provoke-an-acti

And calling setOpenExternalLinks with false does allow the linkActivated signal to function correctly, but then it doesn't open the browser. This looks like a bug as I cannot see why you would have a linkActivated signal that only works when the label is not configured to function as a link.

[mrjj]

@SPlatten said in QLabel signals, linkActivated and linkHovered:

setOpenExternalLinks

Hi
Docs says
"Specifies whether QLabel should automatically open links using QDesktopServices::openUrl() instead of emitting the linkActivated() signal."
So that seems as expected.