Procedure Length Issue
Andre
I just encountered a problem that I have never had a issue
with. I developed a subroutine that was too large to
compile. I looked up the size that a procedure can be and
it is 64K. Mine is 2MB. Does anyone know if there is any
way around this besides the obvious?
Art Marks
"Andre" <dsc...@yahoo.com> wrote in message
news:010c01c2cbbd$9d3fb250$d6f82ecf@TK2MSFTNGXA13...
Surely you jest. How does one get a procedure that large.
--Art
Jeff Johnson [MVP: VB]
> I just encountered a problem that I have never had a issue
You have got to be @#%^%$ kidding.
Tom Esh
O_M_G !
Do you mean ~module~ maybe (hopefully)?
-Tom
MVP - Visual Basic
(please post replies to the newsgroup)
John Shelley
that large?
If you really did manage this, you gotta find a way to break out some of
the functionality into smaller parts (other procs.)
Really... What does this mammouth do?
*** Sent via Developersdex http://www.developersdex.com ***
Don't just participate in USENET...get rewarded for it!
Ken Halter
Code Limitations
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vbcon98/html/vbconcodelimitations.asp?frame=true
"The amount of code that can be loaded into a form, class, or standard module is limited
to 65,534 lines"
"Each procedure can contain up to 64K of code"
There's no reason for a procedure to get *any where near* that size. Once it becomes hard
to figure out what's going on in a procedure or you have the same code over and over, it's
time to break it up.
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com - Please keep it in the groups..
"Art Marks" <arthur...@netscape.net> wrote in message
news:OLMnBX8yCHA.1288@TK2MSFTNGP11...
Les F.
Just keep adding lines of code, code, and
more code. Make sure that there are goto's
aplenty and code on Andre...code on!
Les F.
"Andre" <dsc...@yahoo.com> wrote in message news:010c01c2cbbd$9d3fb250$d6f82ecf@TK2MSFTNGXA13...
Larry Serflaten
Mike D.
I'm in as much disbelief as the others....maybe more. In my worst
nightmare, I couldn't imagine a single procedure being 2 MB in size. I'm
getting the heebie jeebies just thinking about it. My sympathies go out to
whomever needs (I should say "tries") to read that procedure.
There's NO WAY that you're going to get around breaking that procedure up
into MANY smaller procedures, each of which being less than 64K (preferably
much less). In the end, you'll be better off.
I just can't fathom a procedure that large. Any developer worth anything at
all would say that even coming *close* to VB's 64K limit is indicative of a
serious problem with your code. A 2 MB procedure means you're not even on
any scale of this planet, regardless of the programming language. It's
just.....mind boggling.....there are no words to REALLY describe how mind
boggling a 2MB procedure would be. OK....maybe to Einstein or Hawking, it'd
be like 1 + 1 = 2, but for the rest of us...<shudder>.
Mike
<still shuddering at the thought of a 2 MB procedure>
Rick Rothstein
If you show the code you are using, I'll see if I can reduce it to a
one-liner for you. <g>
Rick - MVP
Steve Wood
64K limit...totally frustrating if you ask me. Your 2MB
size is the P-code with debug events and not the Optimized
Native code.
I've been coding for 20 years and can safely say that I
prefer top-down structured coding over the spagetti code
with procedures calling procedures calling functions that
keep a debugger skipping through five or six stacks of
calls...not a pretty site.
Take a look at your code and you will see somewhere to
split it up into meaningful sections. Use a main
procedure to determine which of the several paths
processing should take, then just hand processing over to
that section which you would place in a seperate procedure.
For example, I'm working on a WebClass which provides
unique processing depending on which user logs in based on
their group policy. I am using a case statement to
determine which group the user is in and processing their
page request and post data in that section. It got too
large (got that "procedure too large" error) so I cut each
Case section out and pasted it into a new procedure, then
just call that procedure within the case section.
I'm sure you will see a way to split it up properly.
By the way...congratulations on getting to the point where
you as a developer are hitting the limits of the
development environment.
>.
>
Marc Bernard
news:078901c2cc1d$ff54ca60$d3f82ecf@TK2MSFTNGXA10...
> By the way...congratulations on getting to the point where
> you as a developer are hitting the limits of the
> development environment.
I'm pretty sure this is nothing to be proud of.
Marc
Ken Halter
news:078901c2cc1d$ff54ca60$d3f82ecf@TK2MSFTNGXA10...
> 64K limit...totally frustrating if you ask me. Your 2MB
> size is the P-code with debug events and not the Optimized
> Native code.
>
Rediculous if you ask me. Even 200 lines is pushing it. I have a utility (Project Analyzer
http://www.aivosto.com/project/project.html) that, by default, flags procedures that are
over 67 lines long.. That should give y'all a hint that 64k (or even 1/4 that) is too
much.
Stefan Berglund
<Ken_Halter@Use_Sparingly_Hotmail.com> wrote:
>"Steve Wood" <StevenEd...@cs.com> wrote in message
>news:078901c2cc1d$ff54ca60$d3f82ecf@TK2MSFTNGXA10...
>> Hehe...Andre, don't worry about it. I routinely hit the
>> 64K limit...totally frustrating if you ask me. Your 2MB
>> size is the P-code with debug events and not the Optimized
>> Native code.
>>
>
>Rediculous if you ask me. Even 200 lines is pushing it. I have a utility (Project Analyzer
>http://www.aivosto.com/project/project.html) that, by default, flags procedures that are
>over 67 lines long.. That should give y'all a hint that 64k (or even 1/4 that) is too
>much.
67 lines? It's too long if it doesn't all fit on one screen. <g>
Alex K. Angelopoulos (MVP)
--
Please respond in the newsgroup so everyone may benefit.
http://dev.remotenetworktechnology.com
(email requests for support contract information welcomed)
----------
Subscribe to Microsoft's Security Bulletins:
http://www.microsoft.com/technet/security/bulletin/notify.asp
"Les F." <zala underscore at hot mail dot com> wrote in message
news:ekZyhF#yCHA.680@TK2MSFTNGP11...
Grinder
"Rick Rothstein" <rickNOS...@NOSPAMcomcast.net> wrote in
message news:#zOcgPBzCHA.1924@TK2MSFTNGP12...
I've got a decent implementation of the Deflate algorithm you
can use...
Grinder
He's helped me laugh.
Grinder
> you as a developer are hitting the limits of the
> development environment.
I ran down to the basement this morning, and hit my head on the
ceiling of the stairwell -- are congratulations in order?
Steve Wood
>.
>
Steve Wood
accomplish in a large piece of software like I do then
it's easy to fill up a procedure in one day of coding.
And my procedures tend to grow as I add features. I also
copy code from other procedures over to use...and
sometimes that puts the procedure over the top.
I must also indicate that being able to boast that your
code has a lot of function calls is not something to be
proud of. There are many places in the sample code from
MS that has a function that only has two lines of code in
it. This is just whacky...even if it's used 10 times in
code it would still make more sense to pull the code out
of the function and include it in the main stream code.
The code will run faster and be easier to debug and
maintain. I do admit that it would make it easier to
modify the code if it was in a function so that making a
change to the code would only need to be done once instead
of 10 times. However, I think my code through and find
the best solution and test it thoroughly so that I know it
will work and won't need to be modified. I think the only
function I use in any of my code is to prepare data types
in SQL statements since it needs to be used 100 times on
average in any of my applications and would make the code
harder to manage with the code inline.
>.
>
Steve Wood
that says a procedure with over 67 lines is too long
doesn't mean that it's wrong to have such a procedure. I
wrote a word processor program for DOS that had a SElECT
CASE statement to branch processing for the user
keystrokes which included word wrap, cut & paste, function
keys, etc. There was no way to handle this without
creating a large procedure...unless the procedure was cut
up into pieces like checking for key codes 0 through 31,
then in another procedure check codes 32 through 63, etc.
and if this is done just to keep the procedure size down
then it's just poor programming.
The only reason there is a size limit is due to the
compiler and operating system limits, and not due to
programming style.
Steve
>.
>
Steve Wood
>.
>
dnagel
> compiler and operating system limits, and not due to
> programming style.
There is IMO, a better reason... someone will, one day,
have to re-trace what you have done...
I hope you are gainfully employed at a never expanding
organisation which greatly reduces the chance that someday
I might run into a piece (a big piece at that) of your code...
It might work, work well, run fast and never break... in
fact, I hope it does... but I don't want to come in behind
you...
D.
Ken Halter
flags modules that are over 255 lines (all of these things are user configurable)
> wrote a word processor program for DOS
That really has nothing to do with Windows programming. There are 64k boundries
*everywhere* in Windows that need to be worked with. Besides.. DOS programming is
generally procedural... where as Windows programming is event driven. Everything's a "Sub"
> up into pieces like checking for key codes 0 through 31,
> then in another procedure check codes 32 through 63, etc.
No... it would be one procedure that checks for all of the keys and then makes calls from
that procedure to do the action that's performed by that key. There's still no reason to
have 64k procedures. Just banging away like that is just lazy programming imo.... it also
makes the code generally useless as far as reusablity goes. I like compact self contained
(whenever possible) procedures that can be used in more than one place... or, at least
called from more than one place. fwiw, I programmed quite a few small utilities and a full
blown Monopoly game in DOS (quick basic / assembler).. there may be a chance that the
assembler stuff (no concept of procedures) went up to around 64k but that's pushing it.
Probably more like 32k.
All in all though, I guess that... if you've done it this long, you might as well
continue. The original poster's 2mb is still rediculous.
--
Ken Halter - MS-MVP-VB - http://www.vbsight.com - Please keep it in the groups..
"Steve Wood" <StevenEd...@cs.com> wrote in message
news:089d01c2cc99$8c42dd10$8ef82ecf@TK2MSFTNGXA04...
p...@see_my_sig_for_address.com
Every line of code should be in its own procedure.
Paul ( pjm @ pobox . com ) - remove spaces to email me
>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~>~~
http://helpthecritters.com/ is my domain for helping critters
Coming soon - PMTherm version 2.0 !! http://pmilligan.net/pmtherm.htm
My personal site is at http://www.pmilligan.net ,
featuring free HVAC, psychrometric, stock market, and other software
p...@see_my_sig_for_address.com
Yes - to the ceiling, it is now ahead of you on points :-)
p...@see_my_sig_for_address.com
wrote:
>On Tue, 04 Feb 2003 08:49:51 -0800, Stefan Berglund
><dnulgre...@msn.com> wrote:
>
>>On Tue, 4 Feb 2003 07:27:27 -0800, "Ken Halter"
>><Ken_Halter@Use_Sparingly_Hotmail.com> wrote:
>>
>>>"Steve Wood" <StevenEd...@cs.com> wrote in message
>>>news:078901c2cc1d$ff54ca60$d3f82ecf@TK2MSFTNGXA10...
>>>> Hehe...Andre, don't worry about it. I routinely hit the
>>>> 64K limit...totally frustrating if you ask me. Your 2MB
>>>> size is the P-code with debug events and not the Optimized
>>>> Native code.
>>>>
>>>
>>>Rediculous if you ask me. Even 200 lines is pushing it. I have a utility (Project Analyzer
>>>http://www.aivosto.com/project/project.html) that, by default, flags procedures that are
>>>over 67 lines long.. That should give y'all a hint that 64k (or even 1/4 that) is too
>>>much.
>>
>>67 lines? It's too long if it doesn't all fit on one screen. <g>
>
> Every line of code should be in its own procedure.
>
Possibly every word and every character, if you can arrange
it, too.
Grinder
> of you on points :-)
Quick, pass me a pun-sick bag.
Steve Wood
what is lazy or good programming technique. I think it's
lazy to attempt to construct re-usable code just so it
doesn't have to be typed in again.
In some instances it's a good idea to develop a re-usable
procedure, and I have several of them...one of them uses
the Windows API to work with registy entries, and since it
is the same for any application and has little room for
creativity then it does well as a re-usable module that I
can add to any VB project.
However, I always learn something new when I develop
code. For example when I develop a form that includes
ListView or TreeView controls...I always find some way to
streamline my code to make it faster and/or more stable.
And, since it takes me just as long to modify existing
code to conform to my new application as it is to write
new code I choose to write everything from scratch so that
I can design the code to work seamlessly in the
application while learning new techniques and opening new
doors to features that I didn't think was possible before.
As I said...it's just a matter of preference. Certainly
you don't think I'm lazy because I choose to design and
code something over again do you?
Steve
>.
>
Steve Wood
task of debugging and modifying someone elses code. The
first thing I do is find all the functions and procedures
that have less than 15 lines of code and cut and paste the
code into the sections that call them...so I can follow
the code step by step in the same window. When stepping
through code that calls a lot of functions the cursor
jumps out to a new window...does a few things then comes
back...very irritating and creates a great gap in
concentration with the screen flickering.
I have had other people look at my code and my peers have
all found it easy to follow since it's all there in the
same window...no jumping around. I believe of all the
methodologies to programming there is one that is listed
at the top to use as the main rule...it's called Top-Down
processing which means that the next statement to be
executed is simply the next line. This jumping around was
why we started to disdain the GoTo statement. Now the
same jumping around is happening with lots of Functions.
I hope this helps,
Steve
>.
>
Steve Wood
>-----Original Message-----
>On Tue, 04 Feb 2003 08:49:51 -0800, Stefan Berglund
><dnulgre...@msn.com> wrote:
>
>>On Tue, 4 Feb 2003 07:27:27 -0800, "Ken Halter"
>><Ken_Halter@Use_Sparingly_Hotmail.com> wrote:
>>
>>>"Steve Wood" <StevenEd...@cs.com> wrote in message
>>>news:078901c2cc1d$ff54ca60$d3f82ecf@TK2MSFTNGXA10...
>>>> Hehe...Andre, don't worry about it. I routinely hit
the
>>>> 64K limit...totally frustrating if you ask me. Your
2MB
>>>> size is the P-code with debug events and not the
Optimized
>>>> Native code.
>>>>
>>>
>>>Rediculous if you ask me. Even 200 lines is pushing it.
I have a utility (Project Analyzer
>>>http://www.aivosto.com/project/project.html) that, by
default, flags procedures that are
>>>over 67 lines long.. That should give y'all a hint that
64k (or even 1/4 that) is too
>>>much.
>>
>>67 lines? It's too long if it doesn't all fit on one
screen. <g>
>
> Every line of code should be in its own procedure.
>
And each procedure should have only one parameter! Yes, I
can see the logic! ROFL!
dnagel
| I hope this helps,
|
| Steve
...with every courtesy... no.
D.
Larry Serflaten
>
> I have had other people look at my code and my peers have
> all found it easy to follow since it's all there in the
> same window...no jumping around.
You mean it is easy to step through. Following the code is a
relative term. Try spending a week writing one procedure,
then ask one of your peers to tell you what it does, and how
it does it. Just for comparision, ask them to write something
up that is a drop-in replacement, without taking a second look
at your code.
> I believe of all the
> methodologies to programming there is one that is listed
> at the top to use as the main rule...it's called Top-Down
> processing which means that the next statement to be
> executed is simply the next line. This jumping around was
> why we started to disdain the GoTo statement. Now the
> same jumping around is happening with lots of Functions.
There is an advantage to doing the same task, with the same
piece of code, everywhere it is needed. If that task needs to
be modified, you only have one place that needs modification,
instead of hunting and searching for everywhere in the progam
that task was added inline. To be sure you got them all, you'll
have to re-test your entire application, branching down each
code path at least once. If you later find you need to make
one more modification, you have to again do a hunt and search,
and again do a full test. That is not a very productive way to
make modifications.
The language you are using to write your monster subroutines
operates on that same principle. Everywhere you add a CInt(X)
or Asc(Y) or any number of other intrinsic functions, you are actually
calling (jumping to) the same piece of code for each different
function. Maybe you don't see it, but it happens all the same.
Now imagine you have a task that takes 50 lines of code,
but you need that task done in 1000 different places. You will
not convince many that adding 50 lines 1000 times is better than
adding a single 50 line procedure and calling it 1000 times.
LFS
Larry Serflaten
> As I said...it's just a matter of preference. Certainly
> you don't think I'm lazy because I choose to design and
> code something over again do you?
That is a matter of perspective. One lumberjack uses an
ax to cut and trim 18 trees in a day, another uses a
chainsaw and cuts and trims 20. Which one is lazy?
Failing to learn and apply modern programming techniques
might very well be considered lazy.
LFS
Jane Ransom
<StevenEd...@cs.com> writes
>I have a similar reason. I have many times been given the
>task of debugging and modifying someone elses code. The
>first thing I do is find all the functions and procedures
>that have less than 15 lines of code and cut and paste the
>code into the sections that call them...so I can follow
>the code step by step in the same window.
You do this *every* time the function is called?
Ye Gods!!!
Isn't it easier just to put debug print statements in and forget
stepping?
--
Jane Ransom in Lancaster.
If you need to email me for any other reason,
put jandg dot demon dot co dot uk where you see deadspam.com
Bob Butler
> I have a similar reason. I have many times been given the
> task of debugging and modifying someone elses code. The
> first thing I do is find all the functions and procedures
> that have less than 15 lines of code and cut and paste the
> code into the sections that call them...so I can follow
> the code step by step in the same window.
I would list that as some of the worst advice I have ever seen. I'm glad it
works for you and I wish you all the best but the first thing I'd do with
any of your code is look through it for repeated code and pull it out into
separate functions so that I can debug each individually and then rely on
the encapsulated functionality to reduce the remaing code to more manageable
segments. Procedures that take more than a screen are suspect; any that
take more than 2 are crying for simplification.
Art Marks
> I have a similar reason. I have many times been given the
> task of debugging and modifying someone elses code. The
> first thing I do is find all the functions and procedures
> that have less than 15 lines of code and cut and paste the
> code into the sections that call them...so I can follow
> the code step by step in the same window. When stepping
> through code that calls a lot of functions the cursor
> jumps out to a new window...does a few things then comes
> back...very irritating and creates a great gap in
> concentration with the screen flickering.
Did you ever here of Shift+F8
No jumping to that section of code that you know functions properly.
Shift+F2 is another godsend.
--Art
dnagel
Tie your shoes, walk 10 steps... Untie them, look down
Tie your shoes, walk 10 steps... Untie them, look down
Tie your shoes, walk 10 steps... Untie them, look down
Tie your shoes, walk 10 steps... Untie them, look down
Tie your shoes, walk 10 steps... Untie them, look down
Tie your shoes, walk 10 steps... Untie them, look down
Tie your shoes, walk 10 steps... Untie them, look down
If you ask me thats not lazy, it borders on insane.
D.
"Larry Serflaten" <serf...@usinternet.com> wrote in message
news:exJ52HPzCHA.1840@TK2MSFTNGP12...
p...@see_my_sig_for_address.com
<serf...@usinternet.com> wrote:
>"Steve Wood" <StevenEd...@cs.com> wrote
>
>> As I said...it's just a matter of preference. Certainly
>> you don't think I'm lazy because I choose to design and
>> code something over again do you?
>
>That is a matter of perspective. One lumberjack uses an
>ax to cut and trim 18 trees in a day, another uses a
>chainsaw and cuts and trims 20. Which one is lazy?
The one with the chain saw. If he can't beat an ax by better
than that, he's *damned* lazy :-)
p...@see_my_sig_for_address.com
Crap.
The primary reason for compartmentalizing code via functions
and subs is for re-useability. If a piece of code is referenced
multiple times by various routines, it should exist only once , as a
sub or function, and the routines that need it, call it.
The primary reason for this is quality, in that there is only
one copy of that code snippet that presents itself for possible
bug-monster infestation. And any bugs found get fixed once, not 20
times ( in 20 copies ).
To slice up a procedure into 10 procedures merely for some
arbitrary length restriction is nonsense. If it truly helps make the
main proc more readable, then fine ( the goal there is then
readability, not 'how many screens is it' ), but not if it's some
silly rule like '2 screens worth'.
Art Marks
"Art Marks" <arthur...@netscape.net> wrote in message
news:uMe0C0SzCHA.2552@TK2MSFTNGP12...
> Did you ever here of Shift+F8
can't believe I used that 'hear'