Protecting text in WPF richtextbox

Question

5.00/5 (1 vote)

See more:

I have a generated FlowDocument that I would like users to be able to add to and edit to some extent but much of the generated content should not be editable.

Does anyone know of a reliable way of protecting text within a RichTextBox?

What I have tried:

I've tried catching the MouseDown events on individual flow document blocks and this seems to work most of the time but if I repeatedly click and drag with the mouse, I can eventually get some of the "protected" text highlighted. Curiously, when this does occur, Snoop is not showing any additional events firing and I can't see any pattern in when it occurs and when it doesn't.

This wouldn't actually be a good solution even if it did work as intended because it wouldn't prevent the highlight being dragged over from an adjacent unprotected block.

There is a protect attribute in RTF markup but I can't see any way of adding it whilst adding a block in code and the idea of trying to manipulate RTF code by regex sounds like a lifetime task. I'm suspecting that I'll wind-up having to break protected and unprotected portions of the document down into separate controls but that would be extremely untidy and would still leave issues with areas where I just need to protect portions of text rather than entire blocks or paragraphs.

Posted 5-Jul-16 22:53pm

PeejayAdams

Updated 5-Jul-16 23:18pm

Add a Solution

1 solution

Add a Solution

Add your solution here

Treat my content as plain text, not as HTML

Preview 0

…

Existing Members

Sign in to your account

...or Join us

Download, Vote, Comment, Publish.

Your Email
Password
Forgot your password?

Your Email
This email is in use. Do you need your password?
Optional Password

I have read and agree to the Terms of Service and Privacy Policy
Please subscribe me to the CodeProject newsletters

When answering a question please:

Read the question carefully.
Understand that English isn't everyone's first language so be lenient of bad spelling and grammar.
If a question is poorly phrased then either ask for clarification, ignore it, or edit the question and fix the problem. Insults are not welcome.
Don't tell someone to read the manual. Chances are they have and don't get it. Provide an answer or move on to the next question.

Let's work to help developers, not make them feel stupid.

This content, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Leo Chapiro · Answer 1 · 2016-07-05T23:18:00

Solution 1

That is not exactly clear what you try to achieve.
Can you use two richboxes, one as read-only box just to show the "constant" content and another one nearby / below with the editable content?
As soon as the user is ready, you simple merge the content of both controls.

Would this simply trick solve the problem?

[EDITED]
Please take a look at this solution: String protection in RichTextBox .

Suggestion:

Why don't you use a control inside the RichText box? you can insert buttons and other controls, so i guess inserting a Label or a TextBlock might do what you require.

Answer:
I tried to put some controls in RichTextBox and added some code to protect controls from being deleted, and it worked.

Posted 5-Jul-16 23:18pm

Leo Chapiro

Updated 5-Jul-16 23:43pm

v4

Comments

PeejayAdams 6-Jul-16 5:28am

The document in question is a summary of an estimate - it's potentially a very large document containing a combination of header details, text blocks, itemised activities with hours and prices and various comment fields. At present the summary goes out as it is generated from the data entered elsewhere in the application but we'd like people to be add to the generated parts of the document but not touch anything that relates to the stored data - e.g. we don't want people inadvertently adding a digit to a price.

Leo Chapiro 6-Jul-16 5:38am

Please take a look at this solution: String protection in RichTextBox. The point is, you can use controls like Labels inside the RichText box ...

PeejayAdams 6-Jul-16 5:44am

Thanks, I did look at that route - and may have to go back there in some shape or form - it's not ideal because I simply can't predict all the places where the user might want to insert something. It's also problematic as it makes any global formatting changes somewhat difficult - this is a customer-facing document so needs to be WYSIWYG.