Re: 1.04 Mb with nothing in file ???

Tech-Archive recommends: Repair Windows Errors & Optimize Windows Performance

Thanks for staying with this one for this long.

Is that all macros disabled or just close event code disabled?
That was with all macros disabled.

As I mentioned, I normally don't pay much attention to file size. This may a
non-issue. I'll keep an eye on it though. If I come up with the answer I'll
post it to the ng.

Bart gave me a free registration for Andrew Baker's Workbook Rebuilder. I
will put it to good use. So this has had a silver lining.

Thanks again.

Greg



"Peter T" wrote:

Close to 9 secs. for 700 kb. About 5 secs. when macros disabled.

Is that all macros disabled or just close event code disabled?

File size
seems to be growing too but does reverse also. I'm thinking about
installing
code that monitors it's size over time, logging to a text file. That way I
can see if it stabalizes at some point.

I wouldn't get too hung up over minor fluctuations in file size while
developing. There can be a 2-3 fold difference in size between totally
uncopompiled (just after a clean), fully compiled, and states in between
(after running code for first time). Also other normally harmless garbage
can creep in that's unlikely to impact significantly on save time..

Saves in about 2 1/2 secs. on xl2000 running 2000 Professional. But on
another machine running exactly the same thing takes about 7 seconds. So
I'm
at a complete loss.

Now that really is intriguing! Everything same with the overall state of the
file and Excel + VBE just before the save?
Were the two files made from scratch in respective systems? If not, and the
faster save relates to the system the file was made on might suggest some
difference in references (inlc ocx /controls) assuming both file systems
operating normally.

Afraid I'm out of ideas, not that I had any useful ones in the first place.
However it might be worth focusing on what's potentially different between
otherwise similar systems.. Hopefully you will come up with a little pearl
for the archives :-)

Regards,
Peter T

"Greg Wilson" <GregWilson@xxxxxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:88F0807E-6FDE-43FA-A1C3-BF2591221E0A@xxxxxxxxxxxxxxxx
Close to 9 secs. for 700 kb. About 5 secs. when macros disabled. File size
seems to be growing too but does reverse also. I'm thinking about
installing
code that monitors it's size over time, logging to a text file. That way I
can see if it stabalizes at some point.

I can't think of any code that is unusual besides an Auto_Open macro.
Tested
with it commented out with no effect. Only non-default reference is to
Forms
2.0. Only has two API declarations: GetKeyState and GetCursorPos.

Saves in about 2 1/2 secs. on xl2000 running 2000 Professional. But on
another machine running exactly the same thing takes about 7 seconds. So
I'm
at a complete loss.

The UFs seem to be the worst offenders on file size. I exported all
modules
and then reimported them, checking the file size after each import. I've
been
googling for info on file growth. There is an issue with Pivot Tables.

- Save triggers a recalc, if suspicious replace all formulas with "=" to
"#="

I commented out about 1/3 of the formula with vertually no effect.

Thanks hugely for the help.

Greg

"Peter T" wrote:

I'm under the impression that this
is just the way it is with xl2003 and XP and code modules.

You might be right but I'm not so sure, still seems slow. What's it now,
8
sec for roughly a 1Mb project.? I would have thought if anything xl2003
&
wXP would be faster than xl2000 w2000, but it seems not for you.

Deleted the .xlb file,
Although occasionally the xlb can bloat I can't imagine how it would
affect
this issue.

More long shots before saving:
- close all module windows and then the VBE
- Save triggers a recalc, if suspicious replace all formulas with "=" to
"#="

Regards,
Peter T



.

Relevant Pages

  • Re: Thank you...
    ... period in question" extends "from roughly AD500 to AD1600". ... As for the suggestion that the enthusiasm for "gateway" subjects here just reflects the demographics of participants, this appears to me a rationalisation missing the obvious point: the volume of different off-topic subjects later than 1600 might be explained in this way, and so at a stretch might the number of active participants - though the same people invariably keep quiet on their own earlier ancestry beyond the British Isles - but it does not touch on the weirdly obsessive attitude of Americans in this matter, nor their quest for the "best" lines of royal descent as if proximity to the most recent of long-dead rulers could be a reasonable priority in studying personal ancestry. ... Do they seriously believe that having a dim Plantagenet in the 20th generation is somehow "better" than finding a Connecticut tradesman in the 10th whose life story they can research perhaps for the first time? ... Peter Stewart ...
    (soc.genealogy.medieval)
  • Re: Cannot lock project
    ... > My bet is that you're opening a different file than you're saving. ... Yes always active, selected in vbe project's panel, then save from vbe. ... > Peter T wrote: ... >> password protect my addin. ...
    (microsoft.public.excel.programming)
  • Re: The Tull Thread proves conclusively...,
    ... Love bands for me-I saw them several times in the 70's and Peter ... Gabriel solo once. ... When I saw Bruce the first time in '78, ... jam bands like the Grateful Dead or Pearl -for the others of us, ...
    (rec.music.artists.springsteen)
  • Re: The Cure for Heart Disease Has Been Known For Many Years
    ... Way beyond interesting Peter. ... Although I've read some on Rath this is ... the first time I've read WHY his protocal works. ... Very disturbing so say the least. ...
    (misc.health.alternative)
  • Re: Cannot lock project
    ... Thomas Ramel posted some code that he adds to an addin. ... Peter T wrote: ... >> My bet is that you're opening a different file than you're saving. ... > Yes always active, selected in vbe project's panel, then save from vbe. ...
    (microsoft.public.excel.programming)