Not a bug. Just a limit. Besides it kind of forces you to think
through your code a little bit more (which is usually a good thing).
Super long methods aren't really ideal. As a general rule I
recommend keeping methods to the amount that is readable on a given
screen without scrolling whenever possible. If that method must call
10 or 12 other methods that's fine, but they should also try to
follow that rule too. If you believe that in your case this type of
goal isn't possible I won't argue, but look at your code carefully
before saying that it can't be done. I've rarely seen a case where
things couldn't be broken down and simplified.
No need to wonder about whether it is a bug or not.
On Feb 4, 2007, at 12:45 PM, Terry Ford wrote:
On Feb 4, 2007, at 10:23 AM, Joe Huber wrote:
The error reported was:
Location: Window1.WriteData, line 2069
Error: This method uses 44k of stack space, but the limit is 32k.
End Sub
The actual 5.5.5 project, opened in 2005r4 and 2006r1, operates
fine and shows no stack errors.
I will submit a bug report with the project as a private example
if the owner permits.
In the meantime, does anyone have any similar experience or
knowledge that they could pass on as this is a first for me.
It's not an error. There's a 32kB limit to the size of a stack
frame. Newer versions of RB tend to use up more of the stack frame
for the same code. So if you were close to the limit before, your
code might not work in the newer versions.
The solution is to reduce the size of that method. Refactor it
into multiple methods, reduce the the number of local variables
and parameters, reduce the complexity of if and case statements,
reduce expression complexity and number of expressions to reduce
the number of temp variables BR creates for you.
This has been discussed many times on the list before and the
clear solution is simply to reduce the size and complexity of that
method.
What I don't understand is that the method is quite linear, does
not nest, recurse or call any other method (other than the internal
WriteLine) during its execution and, apart from it being a bit
lengthy and does a lot of concatenation within each the if
conditionals, why should it require a lot of stack space. What is
it that's hogging it? The method doesn't get a chance to run as the
compile fails.
Do we have a new limit on our method lengths that never existed
before?
I can see circular references or recursions causing errors but not
this type of method which has neither.
Still wondering if it's a bug or not.
Terry
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
_______________________________________________
Unsubscribe or switch delivery mode:
<http://www.realsoftware.com/support/listmanager/>
Search the archives of this list here:
<http://support.realsoftware.com/listarchives/lists.html>
