The SelectionStart problem is a real pain.  All I want to be able to do is know the location within the text that the cursor is.  

I can do this if WordWrap is False using the following: 

EditInfo.SelectionStart + Math.Max(EditInfo.GetLineNumber(EditInfo.SelectionStart) - 1, 0)

However, if I have WordWrap turned on then I need to know how many carriage returns there are before the cursor.  The quickest method I found was to create a second, hidden FormattedTextEditor with WordWrap false, copy the text over, and run the above on it, but what a waste of resources...

Secondly, the spell check underlines on the FormattedTextEditor appear in a different place (higher up) than the RichTextBox (see attached image).  Is there any way I can change this so the underline is actually under the text, rather than covering up the bottom of the text?  As it is currently, it's more of a strikethrough than an underline.

I get the feeling this control is not heavily used, as others would have found these problems.

Thanks,
Campbell 

Both problems occur in both versions.  I have attached a sample to demonstrate both issues.

Hello Campbell ,

I try to reproduce your issue, but without success. Could you please tell me what is your version (Are you using version 10.3 or your trial version 12.2) Are you able to upload small sample that reproduce your issue.

Thanks and Regards

What is also very odd about the editor, is that it reports the character position in a strange way if you have carriage returns in the text.  

So say you have the following text: 

ONE TWO
THREE FOUR
FIVE SIX

If you put your cursor after the FOUR,  EditInfo.SelectionStart will return 18.  However, that is actually position 19.  
If you put your cursor after the SIX, EditInfo.SelectionStart will return 27, however that is actually position 29.

In other words, it reports the position of the character as though CrLf was a single character.  But the Text string returned by the control has the CrLf characters as 2 characters in length.

This becomes a problem when you use SelectionStart to identify where in Text you should be looking, and it is actually offset by a certain number of characters. 

Thanks, that certainly resolves the flickering problem, although it is by no means a simple swap over.

One thing I have noticed with the UltraFormattedTextEditor, is if you have a context menu set on the text editor, and you right-click somewhere in the editor, the BeforeToolDropdown event for the context menu fires before the EditStateChanged event on the editor.  So if you build the context menu dynamically based upon the position in the editor (as I am doing, to work out what text is under the cursor) then the context menu picks up the old position, rather than the new.

Is this a known bug?

Thanks,
Campbell