BigDumbDinosaur wrote:
As I’ve said before, I’ve yet to discern a pattern to the error. All I know is it appears when trying to close the S&R dialog box after an S&R session has resulted in a change to the loaded source file. It seems the error is more likely to occur after an extended editing session, which is why I think it’s tied somehow to the undo function—the undo stack will, of course, continuously grow as code is added to the source file being edited. An S&R session that changes a lot of lines will rapidly expand the undo stack, which could be where the error originates.
Another possibility might be an obscure memory leak. I’m not a Windows programmer, so I don’t know enough about that environment to offer any useful guidance.
Looks like it might be a combination of the two. After digging into this it would appear that the CrystalEdit controls Undo records are playing some games with their pointers based on behavior of what the OS may (or may not) be doing, ultimately trying to store single character in the pointer field itself, if that is the size of the undo.
I'm sure this saved some space in memory back in the day, but my experience has been that when you start trying to play games like that with your pointers, it ends badly. Let a pointer be a pointer, and not possibly something else relying on a "trick" that the OS might (or might not) continue to do; or that other programmers have to "remember" is being done in such a non conventional way which leads to bugs later on.
Also appears there's a potential memory leak with that code as well, where the undo record fails to release its memory if multiple calls are made to set it's text.
I'll get the changes made and create a diff file.
Login
Register
FAQ
Search
