Vent on, engage spleen...

Is there anyone on the planet that can provide a cogent explanation of just
what provokes Excel to die with a cheery and modestly colorful dialog
informing you that "Microsoft Excel has encountered a problem and needs to
close. We are sorry for the inconvenience". Further asking you if you want
to attempt to recover your work, a process that to date has proved totally
worthless, and exhorting you to send the gory details to Microsoft, not so
they can actually fix your problem, but to make their product more saleable
in the future. What a set of cojones.

At any rate, we've been laboring on this project for far too long as it is
and now, as it crosses the threshold of completion, this particular
situation pops up far to often to be able to offer the project as a
competent package. We have gone through the entire litany of cleaning code,
reinstalling Excel, getting the latest of updates from the Great White
Fathers is Redmond, etc, ad nauseum. All to absolutely no avail.

Merely entering a normal vanilla value in a normal vanilla cell causes the
thing to fold like a busted flush. That's in one .xls file. In another
seemingly identical file, one can enter things without let or problem. Even
better; the actual VBA code, all of it, resides in a third .xls file and is
in use by all of the other .xls file, them that works and them that doesn't.
We'd be hard pressed to believe that it's the code. One should not be able
to program the untimely and unanticipated death of whatever environment is
supporting your efforts.

Obviously the first .xls file is damaged in some way but just how did this
happen? This is Microsoft dying, not anything we wrote [which functions
flawlessly when the Microsoft code deigns to function]. Moreover it's not
just this file, this happens all the time, every few minutes or so,
willy-nilly with no rhyme or reason on many distinct .xls files, each
ostensibly identical except for data values.

At this juncture we would, philosophically anyway, like nothing better than
to fall back and re-implement the project using an actual language instead
of using a half-assed application whose reach enormously exceeds its grasp.
But that is not to be. We're pretty much stuck with this thing. We can live
with the glacial speeds at which it moves, the incredibly clumsy syntax, the
utter lack of elegance and horsepower, but we really do need the thing to
actually function all the time, every time.

So here's someone's big chance to show that Excel isn't the pale anemic and
functionally worthless piece of **** that it gives every appearance of being
right now. We would like nothing better than to be able to salvage the
endless hours we've invested into this thing. If someone, anyone, provides
that aforementioned cogent explanation, we here at the home will take
appropriate measures to insure that sainthood will be bestowed upon them.

Disengage spleen, vent off....

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

We know you feel better now. Shoulders to cry on and all that.

Surely, this isn't the only instance of a corrupted file in your computing
experience.
Emptying the \temp folder, using scandisk and defrag frequently might help.
I would re-build that file.

"Terry von Gease" wrote in message
...
Vent on, engage spleen...

Is there anyone on the planet that can provide a cogent explanation of
just
what provokes Excel to die with a cheery and modestly colorful dialog
informing you that "Microsoft Excel has encountered a problem and needs to
close. We are sorry for the inconvenience". Further asking you if you want
to attempt to recover your work, a process that to date has proved totally
worthless, and exhorting you to send the gory details to Microsoft, not so
they can actually fix your problem, but to make their product more
saleable
in the future. What a set of cojones.

At any rate, we've been laboring on this project for far too long as it is
and now, as it crosses the threshold of completion, this particular
situation pops up far to often to be able to offer the project as a
competent package. We have gone through the entire litany of cleaning
code,
reinstalling Excel, getting the latest of updates from the Great White
Fathers is Redmond, etc, ad nauseum. All to absolutely no avail.

Merely entering a normal vanilla value in a normal vanilla cell causes the
thing to fold like a busted flush. That's in one .xls file. In another
seemingly identical file, one can enter things without let or problem.
Even
better; the actual VBA code, all of it, resides in a third .xls file and
is
in use by all of the other .xls file, them that works and them that
doesn't.
We'd be hard pressed to believe that it's the code. One should not be able
to program the untimely and unanticipated death of whatever environment is
supporting your efforts.

Obviously the first .xls file is damaged in some way but just how did this
happen? This is Microsoft dying, not anything we wrote [which functions
flawlessly when the Microsoft code deigns to function]. Moreover it's not
just this file, this happens all the time, every few minutes or so,
willy-nilly with no rhyme or reason on many distinct .xls files, each
ostensibly identical except for data values.

At this juncture we would, philosophically anyway, like nothing better
than
to fall back and re-implement the project using an actual language instead
of using a half-assed application whose reach enormously exceeds its
grasp.
But that is not to be. We're pretty much stuck with this thing. We can
live
with the glacial speeds at which it moves, the incredibly clumsy syntax,
the
utter lack of elegance and horsepower, but we really do need the thing to
actually function all the time, every time.

So here's someone's big chance to show that Excel isn't the pale anemic
and
functionally worthless piece of **** that it gives every appearance of
being
right now. We would like nothing better than to be able to salvage the
endless hours we've invested into this thing. If someone, anyone, provides
that aforementioned cogent explanation, we here at the home will take
appropriate measures to insure that sainthood will be bestowed upon them.

Disengage spleen, vent off....

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

"Don Guillett" wrote in message
...
We know you feel better now. Shoulders to cry on and all that.

Surely, this isn't the only instance of a corrupted file in your computing
experience.
Emptying the \temp folder, using scandisk and defrag frequently might
help.
I would re-build that file.


That would be just ducky if it were just that file. The problem is that the
file is lots of files, all differing in data content. Each file represents
a model of an event. To be precise, a sporting event involving horses, big
hair smelly things, and cattle, not so big but hairier and smellier. This is
supposed to be a system to manage this sort of event. You create a sheet,
either from a template or more likely, from a previous event, and start a
new event. No matter how matter how many times we rebuild them, no matter
how many instances, no matter what variation in data, Excel keeps insisting
on dying based on principles apparently unknown to the rest of the civilized
world.

A pragmatic solution like clean up this or that, dust this off, paint this
blue and in the finest tradition of the classic fallacy Post Hoc Ergo
Propter Hoc, the problem seems to go away is not sufficient to continue.
Without a concise statement of necessary and sufficient conditions as to
just what is causing this, other than mice in the washroom, the project will
have to be abandoned.

Unless one knows just what is the cause of something one can never know that
one has fixed it.

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

Think you need to treat this as a prototype and begin moving it to an
"actual language." You will probably be surprised about how quickly you can
duplicate your work in a new environment. You already know what decisions
you made that you wish you had done differently (and now you can since you
are starting from scratch) and you have already worked out the algorithms
you are happy with. You can look at your current state as having created
your architectural plans and even done some initial construction. So
implementing that plan, even with new tools should move along fairly
swiftly.

You say you can't do this, but it sounds like you don't have a choice. You
have done all the general things that usually clear up these type problems -
so it looks like you are in a death spiral. There is no elixer that will
lessen your burden and the impediments are unexceptable. So, time to move
on.

Excel is a worksheet - first and foremost. It isn't a programming language
or a platform for application development. As much as it can serve your
purpose, use it. When it can't move on.


--
Regards,
Tom Ogilvy


Terry von Gease wrote in message
...
"Don Guillett" wrote in message
...
We know you feel better now. Shoulders to cry on and all that.

Surely, this isn't the only instance of a corrupted file in your
computing
experience.
Emptying the \temp folder, using scandisk and defrag frequently might
help.
I would re-build that file.


That would be just ducky if it were just that file. The problem is that
the
file is lots of files, all differing in data content. Each file
represents
a model of an event. To be precise, a sporting event involving horses, big
hair smelly things, and cattle, not so big but hairier and smellier. This
is
supposed to be a system to manage this sort of event. You create a sheet,
either from a template or more likely, from a previous event, and start a
new event. No matter how matter how many times we rebuild them, no matter
how many instances, no matter what variation in data, Excel keeps
insisting
on dying based on principles apparently unknown to the rest of the
civilized
world.

A pragmatic solution like clean up this or that, dust this off, paint this
blue and in the finest tradition of the classic fallacy Post Hoc Ergo
Propter Hoc, the problem seems to go away is not sufficient to continue.
Without a concise statement of necessary and sufficient conditions as to
just what is causing this, other than mice in the washroom, the project
will
have to be abandoned.

Unless one knows just what is the cause of something one can never know
that
one has fixed it.

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

Me thinks perchance that Excel is overloaded. Have you thought of dumping
your info to a database?

-Larry
"Terry von Gease" wrote in message
...
Vent on, engage spleen...

Is there anyone on the planet that can provide a cogent explanation of
just
what provokes Excel to die with a cheery and modestly colorful dialog
informing you that "Microsoft Excel has encountered a problem and needs to
close. We are sorry for the inconvenience". Further asking you if you want
to attempt to recover your work, a process that to date has proved totally
worthless, and exhorting you to send the gory details to Microsoft, not so
they can actually fix your problem, but to make their product more
saleable
in the future. What a set of cojones.

At any rate, we've been laboring on this project for far too long as it is
and now, as it crosses the threshold of completion, this particular
situation pops up far to often to be able to offer the project as a
competent package. We have gone through the entire litany of cleaning
code,
reinstalling Excel, getting the latest of updates from the Great White
Fathers is Redmond, etc, ad nauseum. All to absolutely no avail.

Merely entering a normal vanilla value in a normal vanilla cell causes the
thing to fold like a busted flush. That's in one .xls file. In another
seemingly identical file, one can enter things without let or problem.
Even
better; the actual VBA code, all of it, resides in a third .xls file and
is
in use by all of the other .xls file, them that works and them that
doesn't.
We'd be hard pressed to believe that it's the code. One should not be able
to program the untimely and unanticipated death of whatever environment is
supporting your efforts.

Obviously the first .xls file is damaged in some way but just how did this
happen? This is Microsoft dying, not anything we wrote [which functions
flawlessly when the Microsoft code deigns to function]. Moreover it's not
just this file, this happens all the time, every few minutes or so,
willy-nilly with no rhyme or reason on many distinct .xls files, each
ostensibly identical except for data values.

At this juncture we would, philosophically anyway, like nothing better
than
to fall back and re-implement the project using an actual language instead
of using a half-assed application whose reach enormously exceeds its
grasp.
But that is not to be. We're pretty much stuck with this thing. We can
live
with the glacial speeds at which it moves, the incredibly clumsy syntax,
the
utter lack of elegance and horsepower, but we really do need the thing to
actually function all the time, every time.

So here's someone's big chance to show that Excel isn't the pale anemic
and
functionally worthless piece of **** that it gives every appearance of
being
right now. We would like nothing better than to be able to salvage the
endless hours we've invested into this thing. If someone, anyone, provides
that aforementioned cogent explanation, we here at the home will take
appropriate measures to insure that sainthood will be bestowed upon them.

Disengage spleen, vent off....

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

Excel/VB is a large and complex system and has the number of bugs
appropriate to the MLOC it contains (or possibly slightly more <vbg).

The description of your problem is so generalised (Excel was written by
Microsoft and crashes) that that the advice you are getting matches it in
generality (we sympathise, why not try doing it differently).

If you want some help how about a few concise specifics?

Like how large is your app and what are the key events, methods, controls
and objects etc ...
Whats it doing before Excel crashes?
Have you built in a trace log?

Charles
______________________
Decision Models
The Excel Calculation Site
www.DecisionModels.com

We hesitate for much the same reasons we chose this route to begin with.
That being that the volume of actual data is slight, the GUI management,
especially parallel lists, is pretty much ideal for our purposes, and
everybody on the planet seems to have a copy of Excel. This was positively
bewitching at the onset.

Unfortunately the language supporting it seems to have a problem dealing
with the level of precision, well not precision exactly, intensity or
maybe
depth of elegance would be a better term, required of a typical table
driven
application that must deal with lots of shape changes. There's well over
2,000,000 perfectly reasonable configurations of these events and the
differences can be wildly acute.

Ah well, it was a good idea. We dread implementing all of the fundamental
GUI crap and the printer support and all of that which was what beguiled
us
in the first place. There doesn't seem anything to do for it. If it were
up
to me I think I'd just do it in perl with Tk. That'd be a good choice
except
when dealing with the typical mouth-breathing PC user who's usually only
dimly aware of its own existence. It wouldn't be the running of it, it
would
be the setting up of it that would give any of these specimens the vapors.
Perhaps C, perhaps actual Visual Basic as a long shot. Access might be
interesting but the thing really doesn't need an RDB, in fact it would
just
get in the way. Besides, few have Access and the big kahunas at Microsoft
want far too much money for the Access executable generator.

If there were any realistic and reasonable way to import and export
worksheet data leaving the worksheet itself as a virtual container there
might still be some hope but we fail to see any way to do this out of hand
without a high contrivance index. But, of course, we've come to believe
that
Excel was forged in the workshops of the forces of darkness merely to test
our sanity.

But still...

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley


Terry von Gease wrote in message
...
"Don Guillett" wrote in message
...
We know you feel better now. Shoulders to cry on and all that.

Surely, this isn't the only instance of a corrupted file in your
computing
experience.
Emptying the \temp folder, using scandisk and defrag frequently
might
help.
I would re-build that file.


That would be just ducky if it were just that file. The problem is
that
the
file is lots of files, all differing in data content. Each file
represents
a model of an event. To be precise, a sporting event involving horses,
big
hair smelly things, and cattle, not so big but hairier and smellier.
This
is
supposed to be a system to manage this sort of event. You create a
sheet,
either from a template or more likely, from a previous event, and
start
a
new event. No matter how matter how many times we rebuild them, no
matter
how many instances, no matter what variation in data, Excel keeps
insisting
on dying based on principles apparently unknown to the rest of the
civilized
world.

A pragmatic solution like clean up this or that, dust this off, paint
this
blue and in the finest tradition of the classic fallacy Post Hoc Ergo
Propter Hoc, the problem seems to go away is not sufficient to
continue.
Without a concise statement of necessary and sufficient conditions as
to
just what is causing this, other than mice in the washroom, the
project
will
have to be abandoned.

Unless one knows just what is the cause of something one can never
know
that
one has fixed it.

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

Hi Terry,

Here are my suggestions:

1) First, I'd make sure the problem happens on other machines, with
other versions of Excel, and on other versions of Windows.

2) I think the most likely case is that there is some very subtle
corruption in the sheet that is being copied. Instead of *copying*
that sheet, I'd try *duplicating* it programmatically. In other words,
Workbooks(2).Worksheets(1).Cells(1).Formula =
Workbooks(1).Worksheets(1).Cells(1).Formula, etc.

3) If the problem still happens if you programmatically duplicate the
file like that instead of copying it, then I think the most likely
case would be that you're running into a very subtle bug. To get to
the bottom of that, copy the whole project to a new folder and start
removing as much of it as you can -- code, formulas, everything --
until you have the absolute minimum project that reliably reproduces
the problem. Then, make sure it still reliably reproduces the problem
if you recreate that whole simplified project totally from scratch,
without copying anything (because copying anything could potentially
copy corruption). Then, post the steps to reproduce the problem
totally from scratch, in this thread. Or, call Microsoft Support and
give them the steps to reproduce the problem totally from scratch. If
it does in fact turn out to be a bug, make sure they don't charge you.


Hope this helps,


Greg Lovern
http://PrecisionCalc.com
Get Your Numbers Right



"Terry von Gease" wrote in message
The application has 8 worksheets, 3 of them very hidden. One of them is
always visible, and the remaining 4 may or may not be visible depending on
configuration and circumstances.

The problem seems to lurk in one of the usually hidden sheets. What happens
is after the user uses the application up to the point of invoking the
function that prepares and makes visible this sheet. The function, or series
of functions actually, that do this pretty much constructs the sheet from
one of the very hidden sheets. The very hidden sheet is copied over to the
malfeasant sheet, including lots of cells with lots of conditional [if,
choose, etc.] formulas. There is no problem with cell references coming over
they are all correct, each and every one of them.

At any rate if I shut off calculations and then invoke the process to create
the final sheet, all works fine, except there's no meaningful data of
course. If I then provoke the calculations manually, voila, the bugger dies.

If I leave calculations on and do this it still works and all of the data is
right where it's supposed to be and it's all correct. But if I go back to
the first sheet and attempt to enter another name, either from the keyboard
or from a menu provided by the application, death once more.

Stepping through in debug or setting judicious breakpoints doesn't tell
much, and seems to subtly alter the internal timing such that it seems less
likely to fail when messing around with it. it's when this final sheet is
made visible and activated with normal calculations that the thing sets
itself up to die. Even at that, death comes from other circumstances, this
is simply the one that I can make happen each and every time. By the
principles of basic debuggery, fix this and the others will most likely be
fixed as well. If I knew just what in the hell it was doing to itself.

Vis-a-vis trace log, if it's something for me to implement, no. If it's some
feature of Excel I can't seem to find any reference to it.

Thanks for your interest...

Overall what you describe sounds very similar to many of the applications I
have written that do not have this problem.
One difference is that I build the app as an XLA addin which contains
worksheets on which I put the blocks of data, formulae, formats etc which
the app uses to create the user workbook.

When creating a sheet for the user I do not copy worksheets but create a new
one and transfer the required information at the range level, using
Range=Range and copy paste special for the formats, or copy and paste.

Double check that you have switched calculation to manual before doing the
copy/create process ...

Are you using Excel Defined Names, or are the names you enter just text?

Could you give an example of:
- the code you are using to copy
- the formulae you are copying

If Excel crashes in a repeatable way when calculating after data entry and
you are not using any event trapping then you could try and isolate the
problem to a specific formula by (in Manual) doing a sheet calculate to see
if its a specific sheet, then range.calculate on blocks of formulae etc.
(download my RangeCalc addin if needed)

Voodo checklist:
- Option explicit?
- Do you set all object variables to nothing in reverse container sequence
before exit subs/functions?
- Do you use Rob Bovey's code cleaner?
- Do you delete all temp files in %Temp%?
- What is the size of your .XLB file?
- Any other add-ins loaded?


Charles
______________________
Decision Models
The Excel Calculation Site
www.DecisionModels.com


The application has 8 worksheets, 3 of them very hidden. One of them is
always visible, and the remaining 4 may or may not be visible depending on
configuration and circumstances.

The problem seems to lurk in one of the usually hidden sheets. What
happens
is after the user uses the application up to the point of invoking the
function that prepares and makes visible this sheet. The function, or
series
of functions actually, that do this pretty much constructs the sheet from
one of the very hidden sheets. The very hidden sheet is copied over to the
malfeasant sheet, including lots of cells with lots of conditional [if,
choose, etc.] formulas. There is no problem with cell references coming
over
they are all correct, each and every one of them.

At any rate if I shut off calculations and then invoke the process to
create
the final sheet, all works fine, except there's no meaningful data of
course. If I then provoke the calculations manually, voila, the bugger
dies.

If I leave calculations on and do this it still works and all of the data
is
right where it's supposed to be and it's all correct. But if I go back to
the first sheet and attempt to enter another name, either from the
keyboard
or from a menu provided by the application, death once more.

Stepping through in debug or setting judicious breakpoints doesn't tell
much, and seems to subtly alter the internal timing such that it seems
less
likely to fail when messing around with it. it's when this final sheet is
made visible and activated with normal calculations that the thing sets
itself up to die. Even at that, death comes from other circumstances, this
is simply the one that I can make happen each and every time. By the
principles of basic debuggery, fix this and the others will most likely be
fixed as well. If I knew just what in the hell it was doing to itself.

Vis-a-vis trace log, if it's something for me to implement, no. If it's
some
feature of Excel I can't seem to find any reference to it.

Thanks for your interest...

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley

"Charles Williams" wrote in message
...
Overall what you describe sounds very similar to many of the applications
I
have written that do not have this problem.
One difference is that I build the app as an XLA addin which contains
worksheets on which I put the blocks of data, formulae, formats etc which
the app uses to create the user workbook.

When creating a sheet for the user I do not copy worksheets but create a
new
one and transfer the required information at the range level, using
Range=Range and copy paste special for the formats, or copy and paste.

Double check that you have switched calculation to manual before doing the
copy/create process ...

Why? Can't Exce'l take care of itself?


Are you using Excel Defined Names, or are the names you enter just text?

Could you give an example of:
- the code you are using to copy
- the formulae you are copying

If Excel crashes in a repeatable way when calculating after data entry and
you are not using any event trapping then you could try and isolate the
problem to a specific formula by (in Manual) doing a sheet calculate to
see
if its a specific sheet, then range.calculate on blocks of formulae etc.
(download my RangeCalc addin if needed)

Voodo checklist:
- Option explicit?

No, we're sufficiently mature and are using precous few ad hoc variables
that, by long practice, always have the same monotonic falvor of names. We
reject out of hand the incredible contrivance and unworkable clumsiness of
Microsoft's naming conventions.

- Do you set all object variables to nothing in reverse container sequence
before exit subs/functions?

No we jus tlet them die. Why would we explicity get rid of them. Once again,
can't Excel trake care of itself?

- Do you use Rob Bovey's code cleaner?

Yes, I finally got it to function. Whatever it's supposed to contribute to
the party it doesn't help here. We remain troubled by the notion of a
package drowning in it's own toxic code waste. This in and of itself is
sufficient reason to regard the authors of any such package as functional
amateurs.

- Do you delete all temp files in %Temp%?

Why?

- What is the size of your .XLB file?

Here you have me. What, exactly, is an XLB file?

- Any other add-ins loaded?

No.

This frenzy of cleaning an polishing as a way to eliminate problems it
troubling to us. It implies that Excel and, by extension, all Microsoft
drivel are delicate things and the precise principles of operation are
largely unknown.

Be that as it may. The problem was solved by some weapons grade
simplifications and doing some things explicitly rather that permitting
Excel to do them en passant. Not very satisfying, but it got the job done.

While we readily admit to being cynical curmedgeons, we do offer many thanks
for your interest. It kept those of us here at the home thinking, in our
crude stumbling way, and made us persevere and not toss the whole thing out.

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley



The application has 8 worksheets, 3 of them very hidden. One of them is
always visible, and the remaining 4 may or may not be visible depending
on
configuration and circumstances.

The problem seems to lurk in one of the usually hidden sheets. What
happens
is after the user uses the application up to the point of invoking the
function that prepares and makes visible this sheet. The function, or
series
of functions actually, that do this pretty much constructs the sheet
from
one of the very hidden sheets. The very hidden sheet is copied over to
the
malfeasant sheet, including lots of cells with lots of conditional [if,
choose, etc.] formulas. There is no problem with cell references coming
over
they are all correct, each and every one of them.

At any rate if I shut off calculations and then invoke the process to
create
the final sheet, all works fine, except there's no meaningful data of
course. If I then provoke the calculations manually, voila, the bugger
dies.

If I leave calculations on and do this it still works and all of the
data
is
right where it's supposed to be and it's all correct. But if I go back
to
the first sheet and attempt to enter another name, either from the
keyboard
or from a menu provided by the application, death once more.

Stepping through in debug or setting judicious breakpoints doesn't tell
much, and seems to subtly alter the internal timing such that it seems
less
likely to fail when messing around with it. it's when this final sheet
is
made visible and activated with normal calculations that the thing sets
itself up to die. Even at that, death comes from other circumstances,
this
is simply the one that I can make happen each and every time. By the
principles of basic debuggery, fix this and the others will most likely
be
fixed as well. If I knew just what in the hell it was doing to itself.

Vis-a-vis trace log, if it's something for me to implement, no. If it's
some
feature of Excel I can't seem to find any reference to it.

Thanks for your interest...

--
Terry

"I said I never had much use for one,
I never said I didn't know how to use one."
M. Quigley