I noticed a bug report came in this morning about an error message that didn't make sense to the reporter. I figured this would make an excellent blog topic, since it explains not only the why but the how to fix it.
The reporter had a complex window, and when they would compile their project, they would get an error complaining about "method uses 37k of stack space, but the limit is 32k". Name: NameOfWindowGoesHere" This may seem like a very confusing error message because the name being reported is a window, not a method!
This goes back to a previous blog posting I made about how windows work within REALbasic. A window isn't just this magical thing that the compiler knows about. In fact, the compiler actually has no idea what a window object is! To the compiler, it's just another class and there's nothing special about it. Everything special derives from the IDE rendering out your window object in a way that makes the magic happen.
Part of this rendering out process is a method to handle laying out the super complex window's UI. And this was the part that the original reporter was running into -- the auto-generated code was making a method so complex that the compiler couldn't handle it! So the compiler was reporting the information it had: that particular method was using up too much stack space.
Unfortunately, there is no way to alleviate the issue fully. The IDE has no clue when a rendered method has become "too large", so it can't give you a more reasonable error like "this window is way too complex." And while it *may* be possible to bump the stack size limit up, then someone, somewhere, will have a method that hits the new limit. The IDE could be a bit more helpful in that it could break up the UI layout into several methods for you, however. It may not be fool-proof, and it may slow down window creationg and increase application size. However, it may work (I don't know, I haven't looked at the rendering code for a while).
So how can you fix the issue if you're running into it? Well, the easiest way is to make use of a ContainerControl. Off-load some of your UI into a container control, and that allows you to replace N UI elements with a single one. That will reduce the overhead because the container control is responsible for its own UI, instead of the window being responsible for it.
However, I feel that I should point out: if you are hitting the 32k stack limit, that is a clear indication that something is wrong with your design. Whether it's a method you've coded on your own (which would be a major code design flaw), or a user interface (which is a major UI design flaw) -- 32k of stack space is gigantic. If your user interface has enough controls on it to reach that limit, then you should *really* consider revising your user experience so that it's not so busy. But, at least you know how to work around the issue while thinking about your design! :-)
Time to bump it up to 640k. That ought to be enough for anyone ;)
32 K of stack .. wow ... thats a BOAT load of locals of any kind
Yeah, it's a monster amount of local data (parameters, locals, etc) -- hence the reason it's usually considered a design flaw on the programmer's part. To put this into perspective, that's around 8000 local variables (at rougly 4 bytes per variable).
unless you use something like alloca ...
@sebastiano -- sure, there are other ways to allocate space on the stack too. You could make a structure. Heck, you could make a structure which contains arrays of other structures. ;-) The "4 bytes" rule of thumb stems from the fact that the vast majority of stack data in REALbasic is either an Integer, a String (which is a 4-byte reference) or an Object (also a 4-byte reference).