"Text buffer currupted!"

Delphi 6, WPTools 6.08

I am writing for two reasons concerning this error message.
It is raised in the procedure set_RTFData(x: TWPRTFDataBlock) in the TWPRTFDataCursor class of the WPRTEDefs.pas unit.

First the trivial item - since the text is hard coded in English, I would like to point out that there is a misspelling. "currupted" should be spelled with an O, as "corrupted".

The second issue is little more difficult. As silly as it may sound, "why should this exception be raised?" We recently started getting reports from users stating that this error appeared when saving changes to a document in WPTools.
Our save process consists of using your SaveToFile() method to save the document to a temporary local file. Then we read the contents of the temporary file into a TBlobField of an ADODataSet via its LoadFromFile() method. Then we Post. This has worked well for months now.

Oddly enough, when the exception is raised all of the user's changes DO properly save. I have tried tracing the problem but it occurs something like 1 time out of 50 and I have not been able to come up with any causes. Thus the reason for asking what should cause this problem.

Obviously there is some problem but since all processes seem to work, I have no idea where to turn. Any suggestions?

Hi;

You say you use SaveToFile to save to a tmp file; try to load into WP editor from that file and, if it works, you can be sure the problem is not about WPTools.

I think you are getting some kind of string convertion when you load/save to the database.

Felipe.

Hi Felipe,

Thanks for the reply.

HAVE tried your suggestion before and my test seemed to succeed but, as I said, this problem occurs something like 1 time in 50 so it's not exactly an easily reproducable case. Thus the apparent success of my test case saving to a file and loading it right back into WPTools is no more a true sign of success than the hundreds of times when my existing logic saves to and loads from the database with no error...

I thought about this possibly being a data conversion issue but so far have ruled that out because the same document can have this occur and then not occur in successive editing sessions. If there was a true conversion issue then I would expect the same document to fail repeatedly. There really seems to be no rhyme or reason

For what it's worth, I am not insinuating there is something wrong with WPTools that is causing this error. Rather, I am simply trying to understand what is going on in that particular method that raises an exception. It looks to me like WPTools is trying to determine which RTF data block the cursor was in and grabs that block into its FCursorRTFData field. And if the correct block cannot be found for some reason then the exception is raised.

I know my data did not get corrupted because the resulting documents are fine; I can still print them, edit them, merge variables into them... even call them into Word and look at them. The user's documents seem perfectly fine in 100% of the cases.

If my brief analysis of this WPTools method is correct, my solution may be something as simple as forcing focus back into the document being saved just before posting to the database. I just don't know...

Hi,

thats for the tip.

That exception happens when the paragraph which is supposed to be the current cannot be located.

That is usually dont by WPTools anyway - but may not when you load the text: Reset the cursor position to 0 or a defined value.

Julian

Thanks for the tip. I will give this a try. Just so I don't do something stupid, setting the cursor position to 0 would simply be:

WPTools.CPPosition := 0;

(where WPTools is an instance of your TWPCustomRtfEdit object)
Correct?

To be sure:

WPTools.ActiveText := WPTools.BodyText;
WPTools.CPPosition := 0;

Julian

Thanks!