Procedure Size

[nickwright]

Can any one help me to find out the size of a Procedure, as my code is currently over the 64k limit

[sashi]

Can any one help me to find out the size of a Procedure, as my code is currently over the 64k limit

Hi there,

Am not sure what you meant by "Procedure Size"? No. of words? Which one?Please be clear & simple when asking question as it would ease in providing solution in return. Take care.

[nickwright]

I have a Compile Error stating "Procedure Too Large" - I am unsure on how to deal with this and how to find out the actual size

[sashi]

I have a Compile Error stating "Procedure Too Large" - I am unsure on how to deal with this and how to find out the actual size

Hi there,

This a common problem in VB 6.0 as it doesn't support any procedure above 64K limit. The best approach to deal with this error is to breakdown the procedure into smaller parts, hope it helps. Good luck & Take care.

[SimonBlore]

This is crazy!

You mean to tell me my head can hold more stuff on the fly than my PC can compile?

I have VB Pro 5 and how I am supposed to stop programming, take it apart and put it together in smaller bits, then proceed in any useful manner without just giving up is beyond me...

Is there any patch or fix for this whatsoever?

[SimonBlore]

Anyone else reads this, here's what I did.

Firstly, the message is full of Microsoft's usual **** (pick a four-lettered word). The program will compile will no errors and run without trouble. Why do I feel this 64Kb limit is really not necessary and that 'you only have version 5' is about the best excuse I'm going to hear (when version 5 came out my PC had 640Mb of RAM - that's a lot of procedures I'd have to write). My advice - ignore the error and compile to HDD.

Secondly, even if you reduce said procedure to dozens of lines less than before, you may find you still get this message. (I checked VB's definition of 'a procedure' - it seems that I am right that the primary subroutine is just this) Indeed, after creating another form, removing all reference to the new stuff and cleaning some old code out, I still got the message (and yes, it still compiles and runs if you just try compiling to HDD and testing it from there). My advice - don't hurt your code!

[Killer42]

I'd be curious to know exactly what it was in your code that caused this error. But generally speaking, "reduce the procedure size" is good advice. If it's too big to compile, it's probably too big to make sense of. Break the code into logical chunks. In other words, take out logical chunks of the code and make them Subs or Functions.

It could also mean you are allocating too much memory at the wrong scope. For example, creating a huge array inside a routine.

And yes, probably "upgrade to VB 2005" would be the best advice. VB 2005 Express Edition is available as a free download. I'm sure many limitations will have been addressed by now. (There's also a VB 2008 beta, but I don't know anything about it.)

[SimonBlore]

I'd be curious to know exactly what it was in your code that caused this error. But generally speaking, "reduce the procedure size" is good advice. If it's too big to compile, it's probably too big to make sense of. Break the code into logical chunks. In other words, take out logical chunks of the code and make them Subs or Functions.

It could also mean you are allocating too much memory at the wrong scope. For example, creating a huge array inside a routine.

And yes, probably "upgrade to VB 2005" would be the best advice. VB 2005 Express Edition is available as a free download. I'm sure many limitations will have been addressed by now. (There's also a VB 2008 beta, but I don't know anything about it.)

As far as procedure too big to compile, I would like to know how come VB5 Pro can seem to compile past this error to an .exe outside of the program, which then runs with no errors.

While we're at it, on the point of can I handle a procedure of 64Kb or more... When I did get around to compiling to the .exe - no errors were found. Seems I am quite up to the job (64Kb is hardly a great deal if you keep it tidy and methodical, my calculator used to have half this on it).

So then we get to your point on huge arrays - this is far more likely. I use arrays to hold data in storage so I can manipulate it later. It has worked fine so far too. At present I am passing these from procedure to procedure instead. The arrays are set to a size of 8x10001 cells and 5x10001 cells (double and string respectively). The way I understand computers, system RAM is about the only *convenient* limiting factor (I say this as it would only spill into virtual memory if this filled anyway - and I'd allocate a dedicated 10Gb swap partition if this were the case - it is what I do in Linux and I know from my work it works well in NTFS setups too.

Brings me to the last point - can't see why 64Kb. 640Kb and I'd be far less surprised (that old conventional memory rubbish - thanks, Mr. Gates).

Thanks for your help anyway - I think I'll go get VB 2005 and give it a spin.

Happy coding :)