Tony,
..emf files are small graphic files which depict controls and other graphic
contents which exist on worksheets (I am not sure abour userforms) . If you
have an excel file open which has buttons, etc, goto the WINDOWS/TEMP
directory, select an .emf file, and look at the depiction in your explorer
window.
Apparently, there is only a limited amount of memory that excel can use to
hold these (~1 Meg?), and if there are a lot of these already in the TEMP
directory when you open excel, the memory available to access the valid
..emfs for your app is restricted. Excel then has to use disc access to get
these little graphic files, and that slows down excel critically. (.emf
files are not cleaned out of the TEMP directory whenever there is an excel
crash).
From personal experience, I had an application in the situation described
which took multiplle hours to run, when it could normally have run in a
minute or so.
By the way, adding RAM won't help (if .emfs in the TEMP directory are the
issue). The source of the problem is excel's limitation.
Another reference is
www.decisionmodels.com . Look under the topic
"Bottlenecks/Size"
Alex J
"Tony" wrote in message
...
Paul,
I would not take the PC in for repair at this point as the problem is not
yet isolated. It still could be the memory, but I'm more inclined to go with
the explanation offered by Alex and would exhaust his suggestions first.
One thing you can do is swap the memory (assuming it's the same type of RAM
in both machines that you ran the code on) in the machines. In other words,
take the RAM out of the machine (where the code ran fine) and put in the
machine where the code slowed to a crawl. Likewise, put the RAM (taken out
of the machine where the code slowed to a crawl) and put that in the machine
where the code ran fine. Run the code on both machines again. If the
problem "follows the RAM" it's probably safe to assume it's memory. If you
still have the issue after the memory swap, I'd follow the advice alex
offered.
If the problem does appear to be the memory, call some PC shops and ask if
they charge to test RAM. If you don't find anyone who tests the RAM for
free, I'd probably just buy a new "stick" since it's so cheap right now.
Although it's a possibility that this is memory related, I have a feeling
it's software related.
Alex, what function does the .emf perform?
----- Paul W Smith wrote: -----
Tony,
Thank you for taking the time to offer your comments.
I have run the process on an old and much slower machine with only
256Mb of
RAM, while the machine with the problem apparently has 512Mb. On the
older
machine the code operates without a problem, so it looks like I have
a
problem with my RAM, so your advice was invaluable.
My next question is what do I do to solve this problem? Can you offer
any
further assistance? Do I need to take my PC in for repair?
Paul Smith
"Tony" wrote in message
...
From a Tech Support standpoint when my users complain that any
application
is suddenly slowed down, the first thing I do is delete all of the
tmp files
on the machine. When it comes to Excel, their complaint is generally
that
EVERY Excel file opens and responds slowly. Even though you indicated
that
you're running a subroutine and experiencing this in a particular
workbook,
it still may be worth it to delete all of the .tmp files from the
machine.
I've seen on at least 5 seperate occasions where the .tmp's had
brought
Excel to a crawl and once I deleted those, the problem cleared up
immediately.
Assumimg it's not related to your code, it could also be memory
related in
the sense that after the routine runs for so long, it begins
accessing an
area of RAM that's bad (I've had this happen with other software.)
Likewise,
do you have enough memory?
To rule memory out, run the subroutine on a different PC if
possible.
Although I seriously doubt it's memory related, it may be worth
trying
unless you're convinced that it's somewhere in your code.
Tony