I don't know how much in the way of a delay that would cause on your system
in particular as it's also dependent on the hardware specs, but even for the
system at work, which has a 512MB SDRAM and 800MHz Intel processor, it can
take as little as 5 seconds to as much as 45 seconds depending on what is
being calculated and how much of it. That's for the XP version on W2K Pro.
For the home computer, it's a 1.8GHz Celeron, 256MB SDRAM system, and it
process the calculations faster, but saving and other things tends to run
slower, mostly due to hardware spec differences. That therefore would
explain some timing differences, which is explanable, but the actaul
difference of the behavior is not expected. There's also something like 15
different worksheets.

Like I mentioned, it basically got to the point that it really needs to be
converted over from a spreadsheet to a DB program. The general steps of
creating the DB program was the easy part, but creating all of the user
forms themselves within Access given the issues that I had to deal with,
it's made it that much harder to deal with. I do have certain things ready
to copy over, but still not near as easy and quickly as MS claims Access is
to work with when it comes to forms. If anything, the forms themselves are
very tough to work with in the development stage cause of the error checking
issues that I pointed to before along with other key issues.

"Dave Peterson" wrote in message
...
I use xl2003 and put =rand() in A1:AI65536 (enough to force a delay when
recalculating).

I could interrupt the calculation by hitting the escape key, then type my
new
entry. In fact, if I went to the next cell and started typing,
calculation was
interrupted.

(In both situations, when I finished data entry (and didn't do more), the
calculation of the workbook finished normally.)

I also made a change to one of the cells in the worksheet, saw the
"Calculating
cells #%" in the statusbar. Then I swapped to MSIE. When I swapped back,
calculation was complete.

This doesn't match your description. But I can't explain your results.

"Ronald R. Dodge, Jr." wrote:

At work, we have Excel 2002 (XP). When I type in numbers, it's in
automatic
calculation. Provided as long as I'm not switching back and forth
between
IE and Excel, for when Excel is calculating given it's in automatic mode,
it
still allows me to type in a number in the next cell by stop calculation
until after I have pressed the enter key, then it restarts it's
calculations
again.

At home, I have Excel 2003. Same type of setup, but the only difference,
once it starts calculating, it locks me out from putting any new numbers
until it's done calculating. This means, if I have any set of numbers to
put in, I have to put it into manual calculation, then enter the numbers
in
the various cells, then put it back into automatic.

Yes, I could do the Alt-Ctrl-F9 after I put in the numbers, but why
should I
have it setup that way otherwise. I have one file, which is my financial
file. Pressing the "F9" key by itself is not trustworthy as it rarely
ever
calculates everything within the instance of Excel that the "F9" key is
pressed.

Here's my question: How can I get my Excel 2003 program give the same
calculation behavior as what the Excel 2002 at work does for me? Excel
2003
at home always locks me out for the duration of the calculation while the
only time when Excel 2002 locks me out through the duration of
calculations
is when I am switching back and forth between IE and Excel, which doesn't
happen too often.

Technically, this financial file has gotten to the point that it really
needs to be converted to a DB program. The generic DB programs that's
out
there are just that. They are so generic that I would only be able to do
a
small portion of what I have within my Excel file. Access does have the
capacities that I would need, but it is a bear to have to deal setting up
cause for it to be setup and for it to work not only for keyboard users,
but
also for mouse users while maintaining a stringent error checking
procedure
in place, I had to create my own custom error checking program within
Access, unbind every single form and control in the FE file from the
related
tables and fields respectively in the BE files, along with several other
issues that I have ran into within the Access Jet DB Engine, it's just a
bear to have to deal with it all. The Edit mode doesn't work too well on
the Access Jet Engine while in DAO mode, and the alternative mode of ADO,
it
lacks the dynamic cursor keyset mode cause it's still going through the
Access Jet Engine, which in some cases makes it nearly impossible to deal
with in a multi-user environment. I can more than likely overlook this
last
one for this file in particular given it would be just me for the most
part
using the file, but for what I have went on to setup at work in Access,
it's
been rough, but yet, in some ways, it's the only thing I been able to do
as
our IT department doesn't seem to want to change anything in the main DB
program for supposed fear of upgrades, but yet, the upgrades hasn't even
taken place in the last 4 years minimally.

TIA

Ronald R. Dodge, Jr.
Master MOUS 2000

--

Dave Peterson