Nope -- I only meant the tool I'm building. Compiling and then testing
to see whether file size changes is a good idea -- will check it out.

WHA

On Dec 3, 4:25 am, "Peter T" <peter_t@discussions wrote:
If you have not experienced problems since 'cleaning' the project maybe that
was it, assuming you've not also changed the code.

then hand the tool over to
users when it's ready.

By "tool" do you mean give Rob Bovey's CodeCleaner to users so they can
maintain your app in good condition. I hope not !

Does code corruption ONLY occur when I am working
in the development environment

My initial thought was a firm yes, corruption of the kind that can be
cleaned by export/import of code modules only occurs while developing in the
IDE. However on reflection I'm not so sure, it's a good question. One way to
check would be see if the file size increases after running code and saving,
without the VBE open and not making any other changes to the wb. Would first
need to ensure the code was fully compiled, either with Debug - compile or
by ensuring some code from every module, incl sheet and thisworkbook module,
has been run (on which point note it is normal for file size to increase
after 'cleaning' and then compiling). If you find corruption does reoccur,
sending the CodeCleaner to your users to patch up is not the solution!

It's not inconceivable your project became corrupted during development due
to not releasing those forms correctly, or something related.

Regards,
Peter T

"WHA" wrote in message

...

Oh! That is interesting. In fact, I started using Rob Bovey's
CodeCleaner very recently and have not experienced thememory problem
since. Still, I can't rule out its reoccurrence.

Follow-up question: Does code corruption ONLY occur when I am working
in the development environment (changing code and/or forms, and
testing those changes)? If so, then that would be the best case: I
could run CodeCleaner while developing, then hand the tool over to
users when it's ready. Then I wouldn't have to worry that the users
might experience the Out of Memory error.

Thanks -- WHA

On Dec 2, 9:41 am, Alok wrote:
Hi WHA,

I have been coding VBA for a substantial amount of time and large
projects and have only rarely faced memory leakage problems.

Out of Memory has mainly been because of an unterminated recursive
call. This could be ruled out in your case because you are getting the
error when you are in IDE and are not running any code. Errors in IDE
are mainly because of corruption in the compiled code. This is best
handled by removing each of your modules, class modules and forms to
text files (using the save option when prompted). Then save the
workbook. Close workbook and reopen the workbook and then import each
of the modules, class modules and forms from text files where you
saved them. (This ofcourse can be done more easily by selecting
multiple text files in file explorer and dragging and dropping them in
the VB IDE at one go). There are automated tools out on the internet
for doing this cleanup.

Alok