XL2002 / XP : Crashing problem

[mike_tyrer]

Hi Guys

I recently published a post about a problem I have with a number o
applications which I originally developed under NT/Excel97 and hav
migrated to XP/XL2002.
The spreadsheet applications were completely standalone - no externa
links, but made a lot of use of embedded combo boxes. The application
are robust and sound in the NT/97 world and also run totally robustly o
Win2K/XL2000. The problem is on some, but not all of our XP/XL200
boxes.

Since I migrated the applications we have never been able to get the
stable - across our organisation we have some 4000 PCs, ostensibly al
identical builds. The applications does not crash on all of the PC
but consistently crashes on some PCs, and intermittently crashes o
other PCs. The crashes are consistent - ie the point of crash and th
types of crash: essentially the applications stops working with a
irrecoverable error: quite often on opening there is a runtime error
"cannot create object cmbCountry", "object not found" - refering to on
of the combo's. "object does not exist" refering to a worksheet page,
piece of code runs and the application is returned to the user'
control with half of the screen coloured grey (like the project men
side in the vba editor/or the tree view side in Outlook).

One way I can guarantee to make the application crash is if I compil
the code before saving the application. When I compile the code an
save, the file size is some 25% bigger than if I just simply save th
file.

I am 99.99% certain that I am not using any reserved words within m
code, everything is fully declared and I have looked at every obviou
thing I can. This is a major, major problem which has slowly driven m
demented. We have been trying to fix this for well over three month
now.

The one thing I can point to is this problem appears to start when th
code is compiled. [When a spreadsheet opens the code is compile
anyhow - so what is the difference?]. If the spreadsheet opens an
runs, shortly after opening it is saved (via code) to a user director
with a completely new name - the size of the file does not increment
in the same was as if the vba code was compiled prior to saving.

Has anyone please got any clues as to what could be going on - or wher
I look next - or what tools might be available to thoroughly tear m
code/spreadsheet apart and look for the offending item?

Thanks in anticipation of any contributions - and thank you to those o
you who answered my original post.

Regards

Mike Tyre

 

[Dave Peterson]

Just pure guesses!

I'd try cleaning up the windows Temp folder--excel uses it for lots of
things--including ActiveX controls.

I'd try running Rob Bovey's codecleaner:
http://www.appspro.com/

And if that failed, I'd create a smaller test version to see if that had
trouble. Maybe the workbook is corrupted and has to be rebuilt. This can be an
awful job. I'd do lots of feeble attempts before I gave into that suggestion!

Hi Guys

I recently published a post about a problem I have with a number of
applications which I originally developed under NT/Excel97 and have
migrated to XP/XL2002.
The spreadsheet applications were completely standalone - no external
links, but made a lot of use of embedded combo boxes. The applications
are robust and sound in the NT/97 world and also run totally robustly on
Win2K/XL2000. The problem is on some, but not all of our XP/XL2002
boxes.

Since I migrated the applications we have never been able to get them
stable - across our organisation we have some 4000 PCs, ostensibly all
identical builds. The applications does not crash on all of the PCs
but consistently crashes on some PCs, and intermittently crashes on
other PCs. The crashes are consistent - ie the point of crash and the
types of crash: essentially the applications stops working with an
irrecoverable error: quite often on opening there is a runtime error,
"cannot create object cmbCountry", "object not found" - refering to one
of the combo's. "object does not exist" refering to a worksheet page, a
piece of code runs and the application is returned to the user's
control with half of the screen coloured grey (like the project menu
side in the vba editor/or the tree view side in Outlook).

One way I can guarantee to make the application crash is if I compile
the code before saving the application. When I compile the code and
save, the file size is some 25% bigger than if I just simply save the
file.

I am 99.99% certain that I am not using any reserved words within my
code, everything is fully declared and I have looked at every obvious
thing I can. This is a major, major problem which has slowly driven me
demented. We have been trying to fix this for well over three months
now.

The one thing I can point to is this problem appears to start when the
code is compiled. [When a spreadsheet opens the code is compiled
anyhow - so what is the difference?]. If the spreadsheet opens and
runs, shortly after opening it is saved (via code) to a user directory
with a completely new name - the size of the file does not increment,
in the same was as if the vba code was compiled prior to saving.

Has anyone please got any clues as to what could be going on - or where
I look next - or what tools might be available to thoroughly tear my
code/spreadsheet apart and look for the offending item?

Thanks in anticipation of any contributions - and thank you to those of
you who answered my original post.

Regards

Mike Tyrer

 

[Dave Peterson]

And I think that code is either compile when required or when you demand it. If
you have an uncompile module and have no functions/subroutines in it that are
used, then it won't be compiled.

You can read some notes by Don Baarns (much better than I could explain) at:
http://archive.baarns.com/excel/develop/vbaperfm.asp

Hi Guys

I recently published a post about a problem I have with a number of
applications which I originally developed under NT/Excel97 and have
migrated to XP/XL2002.
The spreadsheet applications were completely standalone - no external
links, but made a lot of use of embedded combo boxes. The applications
are robust and sound in the NT/97 world and also run totally robustly on
Win2K/XL2000. The problem is on some, but not all of our XP/XL2002
boxes.

Since I migrated the applications we have never been able to get them
stable - across our organisation we have some 4000 PCs, ostensibly all
identical builds. The applications does not crash on all of the PCs
but consistently crashes on some PCs, and intermittently crashes on
other PCs. The crashes are consistent - ie the point of crash and the
types of crash: essentially the applications stops working with an
irrecoverable error: quite often on opening there is a runtime error,
"cannot create object cmbCountry", "object not found" - refering to one
of the combo's. "object does not exist" refering to a worksheet page, a
piece of code runs and the application is returned to the user's
control with half of the screen coloured grey (like the project menu
side in the vba editor/or the tree view side in Outlook).

One way I can guarantee to make the application crash is if I compile
the code before saving the application. When I compile the code and
save, the file size is some 25% bigger than if I just simply save the
file.

I am 99.99% certain that I am not using any reserved words within my
code, everything is fully declared and I have looked at every obvious
thing I can. This is a major, major problem which has slowly driven me
demented. We have been trying to fix this for well over three months
now.

The one thing I can point to is this problem appears to start when the
code is compiled. [When a spreadsheet opens the code is compiled
anyhow - so what is the difference?]. If the spreadsheet opens and
runs, shortly after opening it is saved (via code) to a user directory
with a completely new name - the size of the file does not increment,
in the same was as if the vba code was compiled prior to saving.

Has anyone please got any clues as to what could be going on - or where
I look next - or what tools might be available to thoroughly tear my
code/spreadsheet apart and look for the offending item?

Thanks in anticipation of any contributions - and thank you to those of
you who answered my original post.

Regards

Mike Tyrer