Feature Request - Hyperlink Activation Event / Custom Link Handling

[timgray]

The public NavigateUri change in 1.10.3 is working great. I now have hyperlinks saving to Markdown and loading back into AvRichTextBox correctly. I have one more hyperlink integration need that I think could be handled with a very small API addition. My application uses both normal web links and internal application links such as:

gmkeeper://document/

I already plan to disable AvRichTextBox's automatic hyperlink following and let my application handle all activated links itself. What I need is simply a public event that fires when the user activates a hyperlink and gives me the NavigateUri.

Something conceptually like:

HyperlinkActivated
NavigateUri

For example, if the user activates:

https://www.example.com/

My application receives that address and opens the browser itself.

If the user activates:

gmkeeper://document/550e8400-e29b-41d4-a716-446655440000

the app receives that address, recognizes it as an internal document link, and opens the appropriate document inside the application.

The important part is that the activation event would still fire when AvRichTextBox's automatic hyperlink following is set to false. That way AvRichTextBox only needs to report which link was activated. The host application can decide what to do with it, and there is no need to change the existing automatic link-following behavior at all. I can work around this by intercepting pointer events and reproducing the hyperlink hit testing outside the control, but I would much rather avoid coupling the application to AvRichTextBox internals.

The public NavigateUri change solved the storage side cleanly. A simple activation event that passes the link address would solve the other half.

And thanks so much for everything. I very much appreciate all the work you have done.

[cuikp]

Sounds useful. I'll add an event with Uri parameter in the next version, probably within the next few days.

[cuikp]

The latest version (1.10.4) has the event you requested.
EditableHyperlink now has:

public event EventHandler<LinkOpeningEventArgs>? LinkOpening

so you can do something like:

EditableHyperlink myLink = new();
myLink.LinkOpening += MyLink_LinkOpening;
 private void MyLink_LinkOpening(object? sender, LinkOpeningEventArgs e)
 {
     //your logic using e.NavigateUri....

      e.Handled = true;  // prevent default behavior
     
 }

Please try it out and let me know it works.

[timgray]

I wanted to follow up on the hyperlink changes in AvRichTextBox now that I have had a chance to implement them in my application and test everything.

I am very happy with how this works now.

My use case is a little different because I have both normal web hyperlinks and internal application links. The internal links allow me to link one document in the application directly to another document, basically allowing the user to build their own cross references between information.

With the LinkOpening event I was able to handle my internal links inside the application while still allowing normal web links to open normally in the browser.

I was also able to get the editing behavior exactly where I wanted it. Left-click follows the link, while right-click selects the hyperlink and gives the user the existing Edit Hyperlink and Remove Hyperlink options without activating the link. This works for both my internal links and normal web links.

The end result feels very natural to use:

• Left-click a web link - opens it in the browser.
• Left-click an internal link - opens the linked document inside my application.
• Right-click either type - allows the link to be edited or removed without opening it.
• Right-click normal text - behaves normally.

What I especially like is that I was able to do all of this using the public events and functionality already provided by AvRichTextBox. I did not have to modify the library, use reflection, replace the context menu, or build a second hyperlink editor around it.

Thank you for taking the time to make this change and add the LinkOpening support. I know it was a fairly specific request from me, so I really appreciate you taking the time to look at it and provide a clean way for the application to take control of hyperlink navigation.

I hope this ends up being useful to other people using AvRichTextBox as well. Internal hyperlinks can be extremely useful for applications that are using the editor for documentation, notes, knowledge bases, RPG tools, or anything else where one piece of content needs to reference another without leaving the application.

For my application this solved the problem very nicely, and I am very happy with how the hyperlink functionality works now.

Thanks again for taking the time to make the change and for continuing to improve AvRichTextBox.

[cuikp]

Great to hear it's working as expected!

[cuikp]

Hi, I'm about to make a significant change to EditableHyperlink editing under the hood (the current public methods will remain the same, with some optional methods added).

Since you're implementing hyperlinks in your app, I wonder if you'd have time or availability to test that next version to make sure nothing is broken?

[timgray]

Absolutely!

[cuikp]

A preview version (unlisted ver 1.11.0-preview.1) is uploaded now, if and when you have time to test it.

There is actually one breaking change that affects setting hyperlink text:
EditableHyperlink.Text is now set as EditableHyperlink.LinkDisplayText, rather than directly.
using .Text will show a compile-time error prompting to use LinkDisplayText instead.
(This was necessary to allow Undo logging for changing hyperlink texts).