ArgumentException occurs when using the voice typing feature of Windows (started with the Windows Key + H key combo) to convert speech to text in RadRichTextBox.
Exception stacktrace:
System.ArgumentException: 'Requested distance is outside the content of the associated document.'PresentationFramework.dll!System.Windows.Documents.TextPointer.TextPointer(System.Windows.Documents.TextContainer textContainer, int offset, System.Windows.Documents.LogicalDirection direction) PresentationFramework.dll!System.Windows.Documents.TextContainer.CreatePointerAtOffset(int offset, System.Windows.Documents.LogicalDirection direction) PresentationFramework.dll!System.Windows.Documents.TextParentUndoUnit.Do() PresentationFramework.dll!MS.Internal.Documents.UndoManager.Redo(int count) PresentationFramework.dll!System.Windows.Documents.TextStore.RedoQuietly(int count) PresentationFramework.dll!System.Windows.Documents.TextStore.SetFinalDocumentState(MS.Internal.Documents.UndoManager undoManager, System.Collections.Stack imeChangeStack, int appChangeCount, int imeSelectionAnchorOffset, int imeSelectionMovingOffset, int appSelectionAnchorOffset, int appSelectionMovingOffset) PresentationFramework.dll!System.Windows.Documents.TextStore.HandleCompositionEvents(int previousUndoCount) PresentationFramework.dll!System.Windows.Documents.TextStore.GrantLockWorker(MS.Win32.UnsafeNativeMethods.LockFlags flags) PresentationFramework.dll!System.Windows.Documents.TextStore.RequestLock(MS.Win32.UnsafeNativeMethods.LockFlags flags, out int hrSession)
RichTextBox: Bullet list with several levels is not viewed correctly in WordPad.
In Word, this works as expected. When the document is imported into RadRichTextBox, this works as well.
The line break symbol (Shift+Enter) is treated as a text character and it gets measured in the document position calculations executed when you click at the end of the document (somewhere after the line break symbol which ends the line).
This causes two visual issues. The first one is that the caret goes after the line break symbol, which means that when ShowFormattingSymbols is False an empty space (non-existing in the document) is added at the end of the line. Even if ShowFormattingSymbols=true and the line break symbol gets display, it is not expected for ,the caret to get positioned after the symbol.
The second issues is that, when you start typing after you click at the end of the line, the caret position is corrected, but this leads to a jumps of the caret with one character to the left, which brings an unpleasant visual glitch.
To work this around, you can create a custom MouseSelectionHandler and override its RegisterDocumentMouseDown method. This will allow you to check if the caret is placed after the line break symbol and manually update the caret position if that is the case.
public class CustomMouseSelectionHandler : MouseSelectionHandler
{
private IDocumentEditorPresenter presenter;
private RadDocument document;
public CustomMouseSelectionHandler(RadDocument document, IDocumentEditorPresenter presenter)
: base(document, presenter)
{
this.presenter = presenter;
this.document = document;
}
public override void RegisterDocumentMouseDown(bool ctrlPressed, bool shiftPressed, Point position, UIElement originalSource = null, SourceType source = SourceType.Mouse)
{
base.RegisterDocumentMouseDown(ctrlPressed, shiftPressed, position, originalSource, source);
var box = this.document.CaretPosition.GetCurrentSpanBox();
if (box != null && box.AssociatedSpan.Text == "¬")
{
document.CaretPosition.MoveToCurrentLineEnd();
}
}
} this.richTextBox.Loaded += (s, args) =>
{
var presenter = (DocumentPresenterBase)this.richTextBox.ActiveEditorPresenter;
presenter.MouseSelectionHandler = new CustomMouseSelectionHandler(this.richTextBox.Document, presenter);
};
Bold/Italic does not work for some font styles.
This might be a framework limitation in WPF: https://www.telerik.com/forums/some-fonts-are-not-able-to-bold-italic
Sample fonts list:
It seems that the first time a Center TextAlignment is applied to the selection, its length is cached. Because of this, when the selection content (text) changes the length is not updated, thus the text doesn't align properly. It aligns accord to the initial length of the context. The content doesn't update also if the alignment is reset.
To work this around, avoid the FlowNoWrap layout mode and use only Flow.