TRichView.com

Sergey,

Now that the forums are back up, I wanted to continue our discussion from the private newsgroup concerning undo errors. To summarize, I have client who is getting this error when performing an undo in a document. This occurs frequently, and when it does, the document is essentially destroyed.

You mentioned that I probably had an unpaired SetUndoGroup call. I do not use that method at all. In fact, I use the code straight from the actions demo. I did find that in the demo code there was a potential to have mismatched calls as some of the actions did not have the second call to this method in a try..finally clause.

Not only did I add try..finally clauses to all the actions, but I even created a log that tracked each call to the SetUndoGroup method and when the error occured all instances were matched.

Therefore, I have verified that at least at my code level, and the level of the RichView actions, there are no mismatched method calls.

I want to do more investigation on this problem, and I need your help. The error occurs frequently enough and the results are so disasterous that I need to either solve the problem or be able to retrieve the document after this error.

There seems to be only one place this error is generated and that is in procedure TRVUndoList.AddInfo(Info: TRVUndoInfo). Is there any way that I can expose this method so I can create a "backup" of the document before the method is called, and is there a way that upon generation of this error I can restore the original document and give the user a non-fatal error message? What I would really like to do is to save a copy of the document before this method is executed so that when the error does occur I could send the document to you for evaluation.

Any help you can provide is greatly appreciated. I am willing to do as much of the investigative work as possible on my own, but I will need your help in some areas.

Thank you very much.

If this problem can be reproduced, I think the simplest way to find the bug is logging a sequence of undo operations - when they were added, grouped, executed. I'll add this log feature in the next update (I'll try to upload it tomorrow)

The logging feature would be a big help if it is robust enough. What information are you going to provide in the log? Considering that a mismatched SetUndoGroup could still be the cause, are you going to log this also or just the undos? I already know that it is giving the error when an undo operation is attempted, so will the log show more information than just the fact that the undo was attempted? I am not exactly sure how this is going to help me figure out what is occuring PRIOR to the undo that is creating the problem ...

Sergey,

Please disregard my last post. I was thinking that the undo operations only included the actual "Undo" itself and not all of the other method calls that create the undo list in the first place. After I read your post a second time it appears that you addressed all my concerns.

It took a while, but now a new version is availble for registered users.

Undo logging is activated by the compiler define RVDEBUGUNDO (you can add {$DEFINE RVDEBUGUNDO} at the very top of RVUndo.pas).

The log file is "\undolog.txt". It is emptied on the application start.
Only additions to undo and redo lists are recorded, not the calls of Undo or Redo functions (Undo can be detected as adding to redo list, but it's not very convenient). So it would be better if the error will be reproduced without calls of Undo and Redo. But if it's necessary, it's ok.

Informing about the results: as it was expected, the bug was in mismatched SetUndoGroupMode calls.
This bug is in RichViewActions code, in insert hyperlink action.
Fixed in http://www.trichview.com/resources/acti ... tionsb.zip