I've written a pretty advanced application developed under
Excel 2002 that contains dozens of user forms and over
30,000 lines of VBA macro code. I've tested it extensively
to ensure it runs smoothly under any combination of Operating
System (98 Me/2000/XP) and Excel (2000/2002/2003). Nevertheless,
when distributed and run, it will bomb out for a certain percentage
of users with fatal compile-type errors for a variety of reasons during
loading and initialization that are often hard if not impossible to
identify from a distance. The code is protected, of course, so it's
not the result of users fiddling with it.

As an example of what I mean, a user might encounter a compiler
errorin loading the program that says some built-in VBA function
like CHR( ) or MID( ) or the like is unrecognized. I ask users to
go to Tools and select References, but typically everything's
checked that should be checked. So maybe some .DLL among
hundreds got corrupted or was inadvertently deleted, or maybe
there's a hardware or peripheral or environmental conflict. In some
cases a fresh install of the entire Windows operating system and
Office will cure the problem; this does not win me friends, however,
given the down time needed to perform the operation.

But what steps to take and in what order to pin-point the problem
without shutting down and reloading the entire network is quite
beyond my depth. Has anyone you know of set down a detailed
list of procedures that can be followed when such instances occur
to formalize the what and how of examining the operating environment
to help determine and alleviate such problems.

-- Dennis Eisen

The only time I've seen chr() and mid() break like this is when there was a
reference checked, but was marked MISSING.

Since you developed in xl2002, maybe you're using references that don't exist in
earlier versions of excel/office.

Instead of early binding, maybe using late binding would make your life easier.

(use createobject instead of "New Word.Application" kind of stuff.)



DennisE wrote:

I've written a pretty advanced application developed under
Excel 2002 that contains dozens of user forms and over
30,000 lines of VBA macro code. I've tested it extensively
to ensure it runs smoothly under any combination of Operating
System (98 Me/2000/XP) and Excel (2000/2002/2003). Nevertheless,
when distributed and run, it will bomb out for a certain percentage
of users with fatal compile-type errors for a variety of reasons during
loading and initialization that are often hard if not impossible to
identify from a distance. The code is protected, of course, so it's
not the result of users fiddling with it.

As an example of what I mean, a user might encounter a compiler
errorin loading the program that says some built-in VBA function
like CHR( ) or MID( ) or the like is unrecognized. I ask users to
go to Tools and select References, but typically everything's
checked that should be checked. So maybe some .DLL among
hundreds got corrupted or was inadvertently deleted, or maybe
there's a hardware or peripheral or environmental conflict. In some
cases a fresh install of the entire Windows operating system and
Office will cure the problem; this does not win me friends, however,
given the down time needed to perform the operation.

But what steps to take and in what order to pin-point the problem
without shutting down and reloading the entire network is quite
beyond my depth. Has anyone you know of set down a detailed
list of procedures that can be followed when such instances occur
to formalize the what and how of examining the operating environment
to help determine and alleviate such problems.

-- Dennis Eisen

--

Dave Peterson

Hi Dennis,

My strategy is:

- develop under Excel 97, test using higher versions.
- Make sure that the final distributable XLA has been
- cleaned in Excel 97 using Rob Bovey's code cleaner
- compiled and saved by Excel97.

I have not had similar problems to yours (except for DAO/ADO apps but then
you can spot the references problem) but of course that does not mean that
this "voodoo" approach really works.

Charles
______________________
Decision Models
FastExcel Version 2 now available.
www.DecisionModels.com/FxlV2WhatsNew.htm

"DennisE" wrote in message
...
I've written a pretty advanced application developed under
Excel 2002 that contains dozens of user forms and over
30,000 lines of VBA macro code. I've tested it extensively
to ensure it runs smoothly under any combination of Operating
System (98 Me/2000/XP) and Excel (2000/2002/2003). Nevertheless,
when distributed and run, it will bomb out for a certain percentage
of users with fatal compile-type errors for a variety of reasons during
loading and initialization that are often hard if not impossible to
identify from a distance. The code is protected, of course, so it's
not the result of users fiddling with it.

As an example of what I mean, a user might encounter a compiler
errorin loading the program that says some built-in VBA function
like CHR( ) or MID( ) or the like is unrecognized. I ask users to
go to Tools and select References, but typically everything's
checked that should be checked. So maybe some .DLL among
hundreds got corrupted or was inadvertently deleted, or maybe
there's a hardware or peripheral or environmental conflict. In some
cases a fresh install of the entire Windows operating system and
Office will cure the problem; this does not win me friends, however,
given the down time needed to perform the operation.

But what steps to take and in what order to pin-point the problem
without shutting down and reloading the entire network is quite
beyond my depth. Has anyone you know of set down a detailed
list of procedures that can be followed when such instances occur
to formalize the what and how of examining the operating environment
to help determine and alleviate such problems.

-- Dennis Eisen

It sounds very much like some broken references. You see them in your
reference list as MISSING:

I have some code which checks for Broken References:
http://www.vangelder.co.nz/excel/index.html

You could possibly run a check for broken references first thing, before
errors occur by themselves.
I've not thoroughly tested this idea though.

Rob


"DennisE" wrote in message
...
I've written a pretty advanced application developed under
Excel 2002 that contains dozens of user forms and over
30,000 lines of VBA macro code. I've tested it extensively
to ensure it runs smoothly under any combination of Operating
System (98 Me/2000/XP) and Excel (2000/2002/2003). Nevertheless,
when distributed and run, it will bomb out for a certain percentage
of users with fatal compile-type errors for a variety of reasons during
loading and initialization that are often hard if not impossible to
identify from a distance. The code is protected, of course, so it's
not the result of users fiddling with it.

As an example of what I mean, a user might encounter a compiler
errorin loading the program that says some built-in VBA function
like CHR( ) or MID( ) or the like is unrecognized. I ask users to
go to Tools and select References, but typically everything's
checked that should be checked. So maybe some .DLL among
hundreds got corrupted or was inadvertently deleted, or maybe
there's a hardware or peripheral or environmental conflict. In some
cases a fresh install of the entire Windows operating system and
Office will cure the problem; this does not win me friends, however,
given the down time needed to perform the operation.

But what steps to take and in what order to pin-point the problem
without shutting down and reloading the entire network is quite
beyond my depth. Has anyone you know of set down a detailed
list of procedures that can be followed when such instances occur
to formalize the what and how of examining the operating environment
to help determine and alleviate such problems.

-- Dennis Eisen