Depending on the current layout of the document, invoking SetPosition() for a specific location might result in positioning the caret on the line prior to the expected one.
Steps to reproduce:
radRichTextBox.Insert("one: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("two: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("tree: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("four: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("five: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("seks: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("seven: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("eitgh: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("nine: ");
radRichTextBox.Insert(Environment.NewLine);
radRichTextBox.Insert("ten: ");
radRichTextBox.Document.CaretPosition.SetPosition(radRichTextBox.Document.CaretPosition.Location); radRichTextBox.Focus();
Observed: The caret is positioned after "eitgh:"
Expected: The caret shouldn't change its position
In certain rare occasions, double-clicking a table cell may throw:
inline does not belong to this document.
at Telerik.Windows.Documents.Model.RadDocument.GetContainingAnnotationRanges[TRangeStart](Inline inline, Predicate`1 filter, Boolean inclusive)
at Telerik.Windows.Documents.Selection.MouseSelectionHandler.HandleCheckBox(InlineLayoutBox layoutBox)
at Telerik.Windows.Documents.Selection.MouseSelectionHandler.RegisterDocumentSingleMouseDown(Boolean ctrlPressed, Boolean shiftPressed, Point position, UIElement originalSource)
. . .
<p data-telerik-id="Paragraph637567542110611335">
<span data-telerik-id="Span637567542110611345">
Test
</span>
</p>
public class HiResDateTime
{
private static long lastTimeStamp = DateTime.UtcNow.Ticks;
private static readonly Regex digitsOnly = new Regex(@"[^\d]");
public static long UtcNowTicks
{
get
{
long original, newValue;
do
{
original = lastTimeStamp;
long now = DateTime.UtcNow.Ticks;
newValue = Math.Max(now, original + 1);
} while (Interlocked.CompareExchange
(ref lastTimeStamp, newValue, original) != original);
return newValue;
}
}
public static string UtcNowTicksString => digitsOnly.Replace(UtcNowTicks.ToString(), "");
}
The non-breaking space breaks the word if a number character is presented in the word. For example, the following text should be treated as one word - 10,0 % but it is separated into to words - 10,0 and %.
The issue can be observed when the word should break on the next line.
The center text alignment is lost when the last paragraph is copied and pasted.
Steps to reproduce:
- Enter some text and center it.
- Copy and paste it into another document.
Actual: the aligmennt is lost
Expected: the alignment should be preserved
The operating system region and language needs to be set to Japanese.
RichTextBox seems to have several issues with Japanese, but being locked from visibility or edit is the biggest one.
To recreate, start typing in Japanese, push the "right" arrow after selecting the IME option desired, then hit "spacebar." This seems to duplicate the text, then when trying to continue to type into the text field the text is no longer visible (yet the IME does display).
The native WPF RichTextBox has no issues (and also supports partial selection, etc.).
I've attached a video to show the behavior with 2025 Q1 telerik.
*note:* This is on a machine with NVIDIA graphics. I mention this as there may be some issues with RichTextBox and the hardware... When I'm in a virtual machine with a completely Japanese environment and virtual graphics driver, there is NO text visible at all when trying to type into the RichTextBox. Works fine with other controls and wpf RichTextBox.