I believe this refers to the stack limitation introduced with the new
compiler, ie., 5.0. This was not an issue in 4.5.3 and prior
versions. So in going from 4.5.3 to 5.0 I had to deal with this in
several of my methods. It is my understanding that the limitation is
based on the total of a main method, say, plus methods called from a
main method.
I obviously can't answer your question, but my solution was to break
large methods into two or more methods in the Code Editor. Since
doing that I've had no reoccurrence of the problem through 2006r1.
Best,
Jack
On Mar 5, 2006, at 4:07 PM, Paul Rehill wrote:
I have recently found under RB 5.5.5 in Windows, that when a
method's length
reaches some limit that method will stop the project from running
in the IDE
and also as an executable file. This one method, DrawGraph, deals
with a
lot of graphing variations in the project and contains some legacy
code that
can be reworked (ie.reduced) later. To reduce the method's length
to below
the limit, I move sections of the code out which can be time
consuming. I
have started to use ByRef extensively to move multiple lines of
code that
assign calculated values to variables so those variables and values
can be
used further along in the method. Though I am starting to suspect
using
ByRef and moving lots of lines out in this way may not be helping
to reduce
the line count as interpreted by RB. This is as I seem to be
moving a lot
more lines out than I actually incrementally added to the method to
breach
the limit.
When I was part of the RB beta program, I recall someone
complaining that
under RB2005, their project did not run because some methods were
too long.
I recall the advice given to the person was to reduce their method
length.
So at some point, I will upgrade to RB2006 and figure that the
DrawGraph
method will be need to be further reduced in terms of line count.
I am
interested in any comments or experiences of others in moving from
5.5.5 to
RB2005 and later with long methods.
I am also wondering if in RB2006, multi-dimensional arrays can be
passed
between methods. This will make it easier to move code out of
DrawGraph.
Also, have named parameters been introduced like in VB to deal with
optional
parameters when calling functions/methods. One reason for
DrawGraph's long
length is dealing with the lack of availability of named parameters
to cover
the many switches or settings to cater for various graphs. I would
find
it cumbersome to repeat the call to all parameters when passing
them to
DrawGraph without my named parameter workaround that lengthens the
DrawGraph
method.
Regards
Paul Rehill
mathsteacher.com.au
RB 5.5.5 Mac Pro, Mac OS 10.3.6
RB 5.5.5 Win Standard, Win XP SP2
Plugins used: MBS
RealBasic resources: RB Developer, Matt Neuburg's RB book
_______________________________________________
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>
