Sorry, I should have been more specific.  If you change the SpellChecker Mode to AsYouType you should see the flickering.  I verified this in your sample.  It might be more obvious if you increase the font size.

For some reason, the flickering seems to be worst on the top row. 

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. 

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

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

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 

Hello Campbell,

Looking at the provided sample, the mentioned issue with SelectionStart possition is cause from the custom code in the sample. Please take a look at the attached video file for more details.

About the second issue "Secondly, the spell check underlines on the FormattedTextEditor appear in a different place (higher up) than the RichTextBox (see attached image)" - if you want similar behavior like RichtextBox, you could use our UltraTextEditor instead of UltraFormattedTextEditor. Please take a look at the attached screenshot.

Let me know if you have any further questions

Regards

Hello Campbell,

Thanks for provided information. Please note that I create two private cases for you with Ref numbers

- CAS-105976-J5S9G4

- CAS-105977-Z9W9P8

I`ll send you additional information thriugh these cases. Let me know if you have any questions.

Regards

Hi Georgi,

Thanks for replying.  However, I think you are missing the point.  If the UltraFormattedTextEditor contains the text:

ONE TWO THREE
FOUR FIVE SIX
SEVEN EIGHT NINE

If you then place the cursor after the word SEVEN, then SelectionStart reports this as position 33.  However, if you look at position 33 in the Text property returned from the control, this places the cursor after the V in SEVEN.  This is caused by the SelectionStart counting carriage return characters as a single character, whereas the Text property returns carriage returns as 2 characters.  SelectionStart should really be reporting 35 in this example.  This is a bug!  If you don't think so, then please copy and paste this whole reply into the textbox, and show me how I can write code to return the actual word clicked on by the mouse, without having to do some sort of conversion for the carriage returns.

Secondly, your video shows the difference between the character positions in the menu and textbox.  This isn't due to custom code, it is due to the fact that the BeforeToolDropdown event is firing before the SelectionStart property is updated.  Again, this is a bug.  I can work around this by cancelling the menu popup, creating a timer set to 1 millisecond and starting it in the BeforeToolDropdown event, and then building the menu once the timer fires and manually popping the menu back up, but I should not have to do this.

Thirdly, I think it is bizarre that you should show the spell correction underline in a different place just because it is a different control.  Surely that isn't a deliberate feature?  Why would you not make it consistent?  I need to use formatting (font style, colours) hence the initial use of RichTextBox, so assume UltraTextEditor won't fulfil my needs.

Thanks,
Campbell 

Here is the video file