For the purpose of reproducing the behaviour, simply place a RadRichTextBox control on a view, and handle its GotFocus and LostFocus events with the following event handlers, which will write to Visual Studio's Output window so you can see that they've been called.
private void RadRichTextBoxEx_LostFocus(object sender, RoutedEventArgs e) { Console.WriteLine("LostFocus"); } private void RadRichTextBoxEx_GotFocus(object sender, RoutedEventArgs e) { Console.WriteLine("GotFocus"); }
#1 - Clicking the mouse anywhere within the control fires the events
Let's say the RadRichTextbox control has the focus. Clicking the mouse anywhere within the control fires the LostFocus and GotFocus events twice, with the following output in the VS Output window:
LostFocus
GotFocus
LostFocus
GotFocus
I would expect neither the LostFocus not the GotFocus events to be fired, as the control already has the focus.
If the control doesn't have the focus and you click in it (giving it the focus), then the following events are currently raised:
GotFocus
LostFocus
GotFocus
In this situation, I would expect only the first GotFocus event to be raised.
NOTE: I have tried handling the KeyboardGotFocus/KeyboardLostFocus events, and they behave the same way.
#2 - Clicking on a control that doesn't take focus, still fires these events
Let's say the RadRichTextBox control has the focus, and you click on a different control that doesn't steal the focus from the RadRichTextBox control, such as a ribbon button (note, we aren't using the Telerik ribbon currently, but that shouldn't matter). Doing so fires the events like so:
LostFocus
GotFocus
The expected behaviour is that neither of those events should be called.
#3 - When overriding the RadRichTextBox control, neither the OnGotFocus, nor the OnLostFocus methods fire
While this is not really an issue for me, I tried overriding the RadRichTextBox control to add my own behaviour to it, and found that if I override the OnGotFocus and OnLostFocus methods, they never get called. Something maybe to look at as part of this problem.
Please note that all these scenarios have been tried on a plan TextBox control, and it fires its GotFocus/LostFocus events as per my expected behaviour described. Therefore, I would expect the RadRichTextBox control to behave in the same manner.
Thanks
Chris Anderson
11 Answers, 1 is accepted
Thank you for contacting us about this issue.
RadRichTextBox is a quite complex control and uses different UIElements in order to show its content and provide the option to edit the document. For example, in order to show a caret and have it blink when you edit in the document, we use a TextBox. However, this TextBox gets the focus when you click in the editor and returns it to the RadRichTextBox following some internal logic. This causes the GotFocus and LostFocus events to be fired, even though it is not normally expected.
As for the ribbon buttons, they do steal the focus from the editor. The rich text box receives the focus back after they are pressed, because the commands that the ribbon buttons execute force the focus back to the editor.
Can you provide some more details on the goal you wish to achieve?
Iva Toteva
the Telerik team
Time to cast your vote for Telerik! Tell DevPro Connections and Windows IT Pro why Telerik is your choice. Telerik is nominated in a total of 25 categories.
From my tests, the ribbon buttons do not steal the focus from controls. I put a standard text box on a view with a ribbon, and handled its LostFocus event. It only ever gets called when the focus has moved away from the text box. It is not fired when the ribbon buttons are clicked. Therefore I would expect the RadRichTextBox control to behave in the same manner.
Thanks
Chris Anderson
Thank you for the follow-up. It is good to hear that you have found a solution to get it working in your project.
We will log the issue for revision and will try to fix it for one of the future releases.
Iva Toteva
the Telerik team
Time to cast your vote for Telerik! Tell DevPro Connections and Windows IT Pro why Telerik is your choice. Telerik is nominated in a total of 25 categories.
Chris
The confusing raising of events is still not fixed. Big part of the internal UI infrastructure relies on the current implementation, which makes the issue relatively complex. I just created a public item for the internal bug:
RichTextBox: Focus events are not raised consistently
which you can use to track an eventual progress on the matter.
Regards,
Boby
Progress Telerik
The public portal was not present at the time the thread was started, so the bug was logged internally, and I just exposed it publicly. Otherwise, we carefully prioritize the backlog using different tactics, trying to fix the most pressing problems first. The status of the bug is currently not Won't Fix, meaning that we consider it for fixing and re-prioritize it at least quarterly. As of now though, the bug is not scheduled for specific release, so I cannot commit to specific time frame for its fixing.
Could you share what is your exact scenario, we may be able to find a workaround for the issue that suits it?
Regards,
Boby
Progress Telerik
We are having a similar issue with focus not coming back to the radRichTextBox after clicking on a button on the radToolBar (ribbon). We're currently on the February 2017 release of the WPF Telerik controls. Is there any update on this?
The issue seem similar to this one: RichTextBox: Focus is not returned to the caret when the Font Family or Font Size combo boxes are used and the LayoutMode is Flow, which was a regression introduced in R1 2017, and fixed in R2 2017 SP1.
Regards,
Boby
Progress Telerik