"Out of Stack Space" Error

[Cyberdude]

If it's not one thing it's another. The macro I'm writing goes into an intentional loop set for 16 iterations. Each iteration creates a new one-point Series on each of 16 charts. When I ran it so it looped 5 times, it worked OK. When I tried it for the full 16 iterations, then it always fails with an "out of stack space" error.

I haven't determined yet what the max "safe" iterations are, but I'd like to know if there is an inquiry I can make (programmatically) to determine the current status of the stack?

I'm not sure just what it is that's getting stacked. Can anyone enlighten me on that? You would think that 16 iterations of almost anything would work OK. :banghead:

Is there a way to clear the stack?

[Norie]

Can you post your code?

Are you sure it's only iterating 16 times?

I'm afraid I've never seen a solution for returning the values from the call stack.

Usually people ask that question to try and determine which subroutines are calling each other.

[Ivan F Moala]

I suggest you have a look here.
If you are not familiar with the Call Stack then this may help .... as well as others.

http://pubs.logicalexpressions.com/pub0009/LPMArticle.asp?ID=410

[Cyberdude]

Hey, Ivan, that's an excellent reference. It took 8 pages to print it out, but it explains those debug tools that I've been meaning to study and never have. I'm going to now. I can't thank you enough.
Sid

[Norie]

Ivan

I took a look at your link but I couldn't see anything about 'programmatically' accessing the Call Stack.:)

Did I miss something?

[TonyJollans]

Norie,

AFAIK there is no way to programmatically access the Call Stack.

Sid,

You're going to have to post the code for any more help - either you have a machine that's *very* short on resources or you are (accidentally) doing more than you know :)

If it helps, and you haven't already seen it, here's Microsoft's take on the error ..

Possible causes for this error are:

Too many active Function or Sub calls. Check that general recursive procedures are not nested too deeply and that they terminate properly.
Local variables require more local variable space than is available. Try declaring some variables at the module level instead. You can also declare all variables in the procedure static by preceding the Property, Sub, or Function keyword with Static. Or, you can use the Static statement to declare individual static variables within procedures.
Fixed-length strings use more stack space than variable-length strings. Try redefining some of your fixed-length strings as variable-length strings.
Too many nested DoEvents statements.

[Norie]

Norie,

AFAIK there is no way to programmatically access the Call Stack.


Tony

I came to that conclusion myself a while ago , but I thought maybe Ivan was providing a link that showed you how to do it that I'd missed previously.

[Cyberdude]

Thanks to all of you for responding. I regret that I cannot post a copy of the workbook because it's just to complicated and large and it contains a lot of private financial information. There's just no way to reduce the size ... that would of course solve my problem. I can't find any obvious errant recursion. I have been concentrating in reducing the amount of stuff on the charts, since it's clear they slow things down. It has helped somewhat, but I'm still on the edge of overspending the budget (so to speak). I DO have a LOT of variables, so maybe the suggestion to define outside the procedures might help. I'm not clear why making them static would help, but I can try that too.
Thanks again, gang.

[Norie]

Cyberdude

It's not the workbook we'd need to see, it's the code.:)

[Cyberdude]

OK, Norie, I'm attaching a workbook with the offending macro for your dining and dancing pleasure. Make this a low priority item, since I know you must be busy.