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