Setting the URL text for a CMFCLinkCtrl

28 Views Asked by At

If I create a CMFCLinkCtrl control programmatically and assign the text in the constructor all is well. But if I then try to change the URL to something else it does not update visually. According to the documentation for SetURL it states:

Displays a specified URL as the button text.

But when you look at the underlying MFC source for the control all it does is:

void CMFCLinkCtrl::SetURL(LPCTSTR lpszURL)
{
    if (lpszURL == NULL)
    {
        m_strURL.Empty();
    }
    else
    {
        m_strURL = lpszURL;
    }
}

Calling UpdateWindow(); or Invalidate(); on the control made no difference. I then realised that the IDE has two properties:

enter image description here

For Caption is states:

Specifies the text displayed by the control.

For URL it states:

Specifies the url string of the link control.

In the end I simply did this:

m_linkStatusbarLocalCong.SetURL(strCongregation);
m_linkStatusbarLocalCong.SetWindowText(strCongregation);

Now it is working fine. Did I miss something in reading the documentation?

1

There are 1 best solutions below

0
IInspectable On BEST ANSWER

Did I miss something in reading the documentation?

No. The documentation clearly states:

void SetURL(LPCTSTR lpszURL);

lpszURL
[in] The button text to display.

And that is a lie. SetURL() updates the protected class member m_strURL only but doesn't perform any additional steps. If everything else in the implementation was sane this wouldn't be a big deal, and calling UpdateWindow() would reconcile the visual representation with the internal state.

Albeit, nothing in CMFCLinkCtrl's implementation is sane. The code in OnDraw() reaches out and reads the window text for display and never even considers m_strPrefix/m_strURL.

In essence, SetWindowText() controls what's being displayed, and SetURLPrefix()/SetURL() sets the URL to be launched on click. You have to update both so that the display is consistent with the behavior.

I don't know why MFC chose to roll their own CMFCLinkCtrl instead of wrapping a native SysLink control. I do know that it was executed incredibly sloppily.