Delphi 7，TRichedit，被RTF编码困住

Question

I am giving you brief idea about this issue.

1. Retrieving (id,name) fields records from database into list box.
2. Select any record from list.
3. Display Notes (Blob type) into rich edit box for selected id.
4. Except two records all are fine.

5. Both two records has thousands of lines of records into database. Notes : [ It comes from notes being pasted from word or outlook with certain rtf formatting codes. The ones that seem to cause the "sticky note" is where a /f0protect (or something very similar to that) is on the coding. All of the ones that cause problems have this somewhere in the notes pages. The solution is to open the base table record and find the record and display the notes field. Cut/Remove the notes from the base table record and paste them into Word or Notepad (depending on volume). Do lots of Find & Replace on the rtf coding. And re-copy the notes back into the base table record. ]

6. Displaying data correctly into rich edit.

7. Afterward that records, application failed to load another notes into rich edit by selecting another records from list box.
8. Giving a error sound internally.
9. Doesn't throwing any error or exception.

I have three things in my mind for this problem. 1. Problem could be with RTF Codes. 2. Buffer or memory. 3. TRichEdit control.

I hope this explanation would be helpful to help me.

Thanks in advance for help.

Answer 1

First of all I'm going to rephrase your question, because in it's current incarnation (numbered list) it isn't easy to answer. I considered actually editing your question, but that might have been too harsh. I'm only doing this because you're new to the site. If you weren't new I'd simply put in an comment asking "What's the question?"

This is what I think the question should have looked like:

---

TRichEdit miss-behaving with some specific RTF

I'm generating some RTF based on data from a database and loading it into an TRichEdit control. Most of the time it works fine, but in a couple of cases the resulting RTF causes the TRichEdit to miss-behave: It displays the RTF just fine, but when moving to a new record, the TRichEdit simply refuses to load new text! It doesn't throw an exception, but an error-beep is heard from the computer.

Some background: The text that's loaded in the TRichEdit is thousand of lines long, not something that can be easily attached to this message. This RTF is built from smaller bits of RTF, copy-pasted from Microsoft Outlook or Microsoft Word. Apparently the error happens when /f0protect (or something very similar to that) is found in the bits of RTF that came from Outlook or Word. Going into the database and removing those markups fixes the problem, but I need a better solution.

I'm not sure what the problem might be. I'm thinking it's one of:

1. Problem could be with RTF Codes.
2. Buffer or memory.
3. TRichEdit control.

---

And now my answer:

Some background about the RTF format. First of all, it's an Microsoft controlled format that's being continuously revised. You can pretty much save any Word document in RTF format, re-load it in Word and have it look the same. It doesn't mean you can load any RTF into WordPad and have it look exactly as it did in Word! Microsoft is too smart to make such a childish mistake. WordPad is just an wrapper around the Microsoft Rich Text Controll (just as TRichEdit). This implies there are limitations with what TRichEdit can do.

Secondly, the RTF format is not context-free: you can't expect to simply append two peaces of RTF and get valid RTF! An RTF document is supposed to start with an header, followed by the document area. If you append two peaces of RTF you get two headers, and I'm thinking the result is undefined.

You're probably right, the problem is one of the 3 you mentioned. Happily it's easy to test, throw a process of elimination:

1. Buffer or memory: How big is your resulting RTF? Create some equal-length (or larger) RTF from code, making sure it only contains simple RTF. Does it miss-behave? If so, you ran into some kind of memory limitation, but I doubt it. None the less it's easy to test!

2. Problem could be with RTF Codes: Very likely! You say the problem goes away if you remove those offending tags from the database; Remove the tags from code in the process of building the big RTF. If you end up with a long list of tags that need removing, maybe you need to do it the other way around: Make a list of codes you want to keep and removing everything else!

3. TRichEdit control: As far as I know there's no third party rich text editor, so you might as well treat problem (3) the same as problem (1). Saying "This RTF is valid because it works fine in Microsoft Word 2010" doesn't help a single bit, unless you're willing to show your RTF in a Word window using OLE Automation!

Other suggestions:

• Show some code on how you actually build the big RTF.
• If you do find an bad rtf tag and need more info, copy-paste the exact code: /f0protect is not valid rtf!