Memory leak in EM_EMPTYUNDOBUFFER & HEM_RELOADFILE, I'm using the very nice HiEdit.dll control to monitor a file live - refresh the file when there are any changes.
Group: Members
Posts: 7
Member No.: 5797
Joined: 5-March 08
Sponsored Links
I'm using the very nice HiEdit.dll control to monitor a file live (- refresh the file when there are any changes.)
Have tried two ways of doing this but run into problems with both:
* Using RELOADFILE A new copy of the file is created in %temp% on every reload, and old copies don't get deleted. Disk space keeps filling up.
* Using REPLACESEL Tested loading the contents of the file and calling SETSEL + REPLACESEL to replace the current contents of the HiEdit control. When using this method memory usage keeps growing, which seems normal considering it is saving undo states. However, even when calling EMPTYUNDOBUFFER after every REPLACESEL memory usage still keeps growing, until my program crash. I can see that the undo option is greyed out so HiEdit has cleared the states properly, however not the memory it seems?
Should I be calling any of the functions in a different way (or is there a smarter way to accomplish what I'm trying to do..?), or could this be a bug?
Group: Admins
Posts: 2308
Member No.: 1
Joined: 12-May 04
Hi tomte,
Thanks a lot for your good words about HiEdit.
QUOTE
* Using RELOADFILE A new copy of the file is created in %temp% on every reload, and old copies don't get deleted. Disk space keeps filling up.
You are probably right; I 'll have a look at the sources and see why the temp file is not deleted.
QUOTE
* Using REPLACESEL Tested loading the contents of the file and calling SETSEL + REPLACESEL to replace the current contents of the HiEdit control. When using this method memory usage keeps growing, which seems normal considering it is saving undo states. However, even when calling EMPTYUNDOBUFFER after every REPLACESEL memory usage still keeps growing, until my program crash. I can see that the undo option is greyed out so HiEdit has cleared the states properly, however not the memory it seems?
I 'll give this a look too and see if and why the memory is not released. If this is the case I 'll fix it.
All in all, I would use the RELOADFILE method which should be a lot faster and cleaner.
Thanks a lot for reporting these issues, I 'll let you know when I have some (hopefully good) news.
Group: Members
Posts: 7
Member No.: 5797
Joined: 5-March 08
Hi Antonis,
Many thanks for your quick reply. I found SETTEXT was a bit cleaner than what I was doing with SETSEL + REPLACESEL (though it has the same memory behaviour). But as you say I'm sure RELOADFILE would be the best.
I hope you find the bug report useful, and many thanks again for this excellent control.
Close Topic Options