Tim,

Thanks. The reassurance about the utility -- and the problem it was designed
to fix -- is helpful.

I agree that complicated code can sometimes be flaky. If you can't exactly
reproduce the input conditions, you can't reproduce the error. The input
conditions might have depended on all kinds of things in the outside
environment. Earlier in my career I encountered this in complex embedded
programs. These are actual subtle coding errors, not errors in the platform.

However, I am dealing here with pretty straightforward code. It's not
event-driven, it doesn't do any file or database manipuation, it simply
looks through the Excel worksheets and verifies that the data passes some
simple tests. In an example like this, it's hard to imagine that identical
code, run on identical data, would give different answers. To me, it's more
reasonable to look at the platform in this case.

And no, there are no DLL calls in the program. As I say, it's really very
simple code.

I completely agree that this code is production worthy. My problem right now
is political -- convincing my manager (I'm new to this project, and haven't
fully earned my new boss's respect) that the code has been tested enough,
and the explanation I'm giving him (basically: Look, this is Windows
programming, sh*t happens) is believable. In the programming world he comes
from (mainframe & unix), if you run into a problem, you don't release your
code until you've reproduced the error, and then fixed whatever caused it.
I'm trying to tell him we just can't do that here. (And running a third
party utility, where he has no access to its source code, would probably
give him a heart attack!)

I appreciate the time you're giving me. Thanks.

Naomi



"Tim Williams" <timjwilliams at gmail dot com wrote in message
...
Naomi,

It is a common finding (in this newsgroup at least) that the process
described by the site you visited does help. During the develoment
process
Excel files do build up "junk" which can only be removed by exporting and
re-importing code modules. The utility they recommend is free, so there
is
no ulterior motive on their part, and many other posters here have
confirmed
it does work.

We all manage at some point to introduce errors in our code which later -
sometimes after some "unrelated" changes - cannot be reproduced. This in
iteslf is not a failing of the platform, but a normal part any coding
(no-one is perfect). As long as you have a set of tests which your code
passes, and you feel the set of tests is enough to judge "production"
quality, then that would seem to be sufficient.

The original post mentioned something about a dll error - does the code
call
procedures in an external library (API calls?)

Regards,
Tim





"J.D. Hildebrand" wrote in message
news:uZ%_f.11632$_T5.3381@trndny08...
Tim,

There was the 12:30 version of the Validate routine, which ran without
error.

There was the 1:30 version of the Validate routine, which had *only
comments* added, but no executed code changed. This version gave an
error.

There was the 2:00 version of the Validate routine, which was identical
to
the 1:30 version except that the Validate routine was renamed to
ValidateData. This ran without error.

There was the 5:00 version of the Validate routine, which was identical
to
the 1:30 version: I renamed ValidateData back to Validate. This ran
without
error.

All of these were within a single spreadsheet, abcde.xls, my "testing"
spreadsheet.

In addition, I tested 140 spreadsheets with the 2:00 version of the
Validate
routine -- yes, the identical version -- and all ran without error.

The fact that the 1:30 version and the 5:00 version had the *identical*
VBA
leads me to believe that the problem is not in my code. I suspect there
is
a
problem with Excel, or with my spreadsheet, that it is somehow sort of
corrupted.

I found a website, http://www.dotxls.com/excel-recovery/40/ , which says
the
following:
"During the process of creating VBA programs, a lot of "junk" builds up
in
your files. If these files aren't cleaned periodically you will begin to
experience strange problems caused by this extra baggage. Cleaning a
project
involves exporting the contents of all its VBComponents out to text
files,
deleting the components, then importing the components back from the
text
files." "You will often see a dramatic reduction in file size once
you've
done this. Even after recompiling the code..500k-600k projects routinely
drop 100k if they haven't been cleaned recently. This is all useless,
error
prone garbage getting thrown out of your file."
Reduce Excel File Size / VBUSERS Excel File Rebuilder
"The rebuilder has been primarily designed for developers to help
stabilise
and compact Excel Workbooks. Rebuilding workbooks containing VBA code
and
references to COM objects results in the workbooks becoming more stabile
and
reducing in size by up to 70%. The rebuilder also overcomes many common
problems including unexplained 'Bad DLL Calling Convention' errors,
Excel
locking up while saving workbooks and 'Application undefined error'. The
rebuilder will also automatically check all references and if necessary
repoint any invalid references."

I don't know if they're just trying to sell a product or not. Does their
explanation make sense to you, as a way of explaining what happened to
me?

Thanks.

Naomi


"Tim Williams" <timjwilliams at gmail dot com wrote in message
...
No error, no code.... I doubt anyone would be able to provide a "spot
on"
explanation for this.

Is the Validate routine exactly the same in all of the files?

Tim