Drag-and-drop from readonly RichTextBox should not alter source

Drag-and-drop from readonly RichTextBox should not alter source by msorens

Closed

as Won't Fix Help for as Won't Fix

Type:	Bug
ID:	484904
Opened:	8/24/2009 8:49:50 AM
Access Restriction:	Public

Workaround(s)

view

User(s) can reproduce this bug

In a .NET application, if one sets a control to read-only it is reasonable to expect that one could still alter its contents programmatically but that the user should not be able to change its contents by editing or by dragging. It turns out that one cannot edit it by typing but one can remove some or all of its contents by dragging.

I first submitted this to the MSDN C# forum (http://social.msdn.microsoft.com/Forums/en-US/csharpgeneral/thread/43fe6ae1-b7c6-43cf-9fb5-97ad8131e7db) and was told that the behavior is "as designed".

I wanted to elevate the issue here to at least present the case that, in my opinion, allowing dragging out to delete text is *not* properly honoring the read-only property.

Details (expand)

English

.NET Framework 3.5 SP1

Windows XP Professional

English

1. Create a simple WinForm test application (I can supply the code on request) containing two RichTextBoxes, one set to read-only and both with EnableAutoDragDrop set true.
2. Pre-load the read-only control with some text (i.e. in the program code).
3. Run the application.
4. Drag some or all the text from the read-only control to the other one.

The selected and dragged text is moved (i.e. deleted) from the supposed read-only control.

The selected and dragged text should be copied, not moved. The contents should be immutable since it is set to read-only.

Thanks for reporting the issue.

Customer feedback is a critical part of a successful, impactful product release. Unfortunately another part is the reality of schedules and the need to get the bits into production. We have evaluated the issue that you reported and it does not meet the criteria to be addressed in this release. This evaluation is carefully done and considers many aspects including fix cost, breaking changes, globalization, performance, etc.

Many customers have found it useful to discuss issues like this in the forums (http://forums.microsoft.com/msdn/default.aspx?siteid=1) where Microsoft and other members of the community can suggest workarounds.

Before we even begin work on the next release of the NET Framework release where we can make changes like this one we will devote time to addressing the top issues/suggestion (in terms of number of votes, lack of workarounds, etc). So please do continue to vote for this item if it is causing issues.

Thanks,
UIFx Team