How many ActiveX controls can I have? Stack overflow problems...

  • Thread starter Thread starter Jim
  • Start date Start date
J

Jim

I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).

Clearly (and as I write this, it becomes more apparent), this is a
good contender for stack overflow. (Having said that, the old version
of the database I wrote had the tree control and combo boxes, yet
didn't run into any problems)

My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time? Would I have to compromise and close each form before
opening another?

Also, how can I assess how full the stack is, so that I can anticipate
an overflow ahead of time?

Any help greatly appreciated
Jim
 
My question is, would I have a stack overflow if I split the above
mentioned form into three separate forms, yet had them all loaded at
the same time?
Click to expand...

Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that
you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather
than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly
say whether splitting it up, would fix the problem. Maybe it would - maybe
it wouldn't! AFAIK there is no magic forumla where someone could plug in the
number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you
will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC
 
Thanks very much for your reply. I clearly don't understand stacks.
Can someone explain how they work with regards Access? I've just spent
several hours trawling the web, and popped down to Waterstones by
Piccadilly Circus (apparently the largest bookstore in Europe) and
found absolutely nothing useful.

Thanks
Jim
 
I doubt you'll ever get any very specific answer to this question, Jim, but
in general terms, that sure sounds like an impractically complex form to me.
This opinion is not based on any deep understanding of the internal workings
of Access, VBA, or the stack, but purely on personal, subjective experience.
But for whatever it might be worth, I would never, in my wildest dreams,
contemplate attempting to create a form as complex as that.

--
Brendan Reynolds

Jim said:
Thanks very much for your reply. I clearly don't understand stacks.
Can someone explain how they work with regards Access? I've just spent
several hours trawling the web, and popped down to Waterstones by
Piccadilly Circus (apparently the largest bookstore in Europe) and
found absolutely nothing useful.

Thanks
Jim



Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that
you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather
than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly
say whether splitting it up, would fix the problem. Maybe it would - maybe
it wouldn't! AFAIK there is no magic forumla where someone could plug in the
number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you
will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC
Click to expand...
[/QUOTE]
 
Jim said:
I have spent the past few weeks designing a database for my company.
The problem is I have started running into what I believe are stack
overflow problems. There are two tab controls on the form (nested),
three list views, one tree control with up to 30,000 nodes, maybe 15
comboboxes (half of which have a large recordset as rowsource), 20 or
so buttons and around 30 text boxes (not to mention the images,
labels, etc and around 1000 lines of VBA behind it all).
Click to expand...

Jim,

As the others have noted, your problems aren't stack overflows. Actually,
you don't specify exactly what kind of problems you are having. Your form
isn't very complex, yet, but it appears to be heading that way. You might
lighten it up a bit by moving some things to another form, and moving most
of the code to a public module.

I've also built large, complex main forms, with two nested tab controls, 15
or so subforms, 100 text boxes, 2500 lines of code, 20 click buttons, linked
images, 10 option groups, 20 small-recordsource comboboxes, etc. and not
had any stability problems. But I eventually got a little worried, and
lightened it up. If that one form gets corrupted, you might have a
difficult time replicating it.
 
A few more details on the below problem:

The database works perfectly well on my PC. It will not work on other
PCs (all PCs in my office use Win2K and Office2K.

The error used to be that Access would simply crash (MS Access has
generated errors) and closes. After I installed some patches for
Win2K, the error then became 'Run time error 28 - out of stack space.'
Upon receiving this error, Access either crashes or closes down. I
can't see any other differences between the installations on each PC.

I'm baffled as to why my PC works, but others don't. Any ideas would
really be appreciated.

Also, as per my other reply to your message, any help on what stack
overflows mean etc would really help as I am by no means an expert and
have been unable to find any decent literature on the subject..

Thanks
Jim
 
Jim, I agree with Brendan. You need to be concerned with the size of stack
storage, only when you are writing in a low level language like assembly
code. Writing in Access VBA is waaaaaaaaaaaaaay above that level. There are
people in this ng who have written hundreds of thousands of lines of Access
VBA code. None of them would have been thinking about stack size, at any
stage, IMHO.

I've just seen your other reply providing more details, so I'll switch to
that one now :-)

Cheers,
TC
 
I take it that your home PC is also win2k & office2k?

Here's what I'd try.

First, on the off chance there is some curruption in your database: create a
new db & import all the objects from the old db. Then open any code module &
do a "compile & save all" (from the Debug menu, I think; I don't have Access
here to check). Confirm the new db works ok on your home pc.

Then take it to the office pc, & see if it works there. Use exactly the same
sequence of actions, that you use on the home pc. (Eg. double-click the
databsee, run the startup form, select main menu option #123 - whatever.)

If it works, maybe you have solved your problem. If it doesn't, please tell
us exactly what is the sequence of actions involved; that is: "I do this -
it does that - I do the other", etc.

As for the stack overflow: it is possible to get stack overflows by making
certain kinds of programming errors. But if that were the case, the error
would happen at home, as well as the office - >unless< you are taking a
different series of actions in the two locations. That is why it is
important to follow exactly the same sequence of actions, in each location,
when you do more testing.

HTH,
TC



Jim said:
A few more details on the below problem:

The database works perfectly well on my PC. It will not work on other
PCs (all PCs in my office use Win2K and Office2K.

The error used to be that Access would simply crash (MS Access has
generated errors) and closes. After I installed some patches for
Win2K, the error then became 'Run time error 28 - out of stack space.'
Upon receiving this error, Access either crashes or closes down. I
can't see any other differences between the installations on each PC.

I'm baffled as to why my PC works, but others don't. Any ideas would
really be appreciated.

Also, as per my other reply to your message, any help on what stack
overflows mean etc would really help as I am by no means an expert and
have been unable to find any decent literature on the subject..

Thanks
Jim




Jim, how could anyone possibly answer that question?

First, you haven't given any information on what leads you to believe that
you are getting stack overflow errors. What is the message or other
condition that is leading you to that belief?

Second, if you >are< getting stack overflow errors, you would need to
determine that this is actually due to the complexity of your form, rather
than a coding error (eg. an infinite recursive procedure call).

Third, if it >is< due to the complexity of your form, no-one could possibly
say whether splitting it up, would fix the problem. Maybe it would - maybe
it wouldn't! AFAIK there is no magic forumla where someone could plug in the
number of items & get a yes/no answer back.

I'm not disagreeing that the complexity of your form is causing your
problems (whatever they are). I'm just suggesting that there is no way you
will get any "yes/no" answers to your questions, as you have currently
phrased them.

HTH,
TC
Click to expand...
[/QUOTE]
 
Why don't you take a look at this:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/office97/
html/minimizingstackusage.asp

This was written for Office/Access 97, but the concepts will most likely be the
same. It might give you some things to consider.

Problems seem to be things like too many local strings (strings defined within
functiions) and/or the way those local strings are defined, too many functions
calling functions calling functions... or functions calling themselves,

If you don't understand what it's talking about then post back again.

Rick
 
BTW, I'd be very suspicious of your tree control (especially with 30,000
nodes). I'd bet that you have a recurcive call there in order to populate the
tree... that's one of the main causes of "out of stack" conditions.

Rick
 
Thanks for all your comments. I'm beginning to suspect that I don't
have a 'clean' install of either Windows or Office. The form works
fine on my PC, but after a certain amount of usage, I get an 'out of
memory - please close other apps' message, after which the labels and
other form text changes to 10pt fixed-sys font (ie the form starts to
look crappy). Still doesn't work on any other PC that I've tried.

On the stacks issue, I accept your comments that it's not a stack
space problem. I wonder if someone could point me in the direction of
some good reading material where I can learn more about stacks and how
they work in relation to Access.

Again, I really appreciate all your comments. Thanks.
Jim
 
Jim said:
I wonder if someone could point me in the direction of
some good reading material where I can learn more about
stacks and how they work in relation to Access.
Click to expand...

-------------------------------
Moving away from Access for a moment for the backstory....

The stack is a part of every thread that runs under Windows. When the thread
is created it is given a specific amount of memory space, known as "the
stack" -- usually 1mb but you can set it higher or lower if you need to.
This is the memory that is easiest to use as it is right there. Every time
you call a function, the computer remembers where you are in the stack and
marks it. The local variables like Integers and Longs get allocated right
off the stack, and then when you exit the function, the computer remembers
where it was and basically "forgets" all of the stack after that point, thus
allowing a cheap way to deallocate local memory.

Now stack is very easy, as the above indicates. The problem is that there is
only so much of it -- so you do not want allocate huge buffers on the stack.
And every time you call a new procedure it "pushes more stack" for that
procedure's local variables. This is why a recursive function can lead (in
VBA) to an "Out of stack space" error -- because each call pushes a little
more stack until there would have been none left. VBA is nice though (in C
you would just crash -- its harder to recover from these errors than most
people know how to handle!).

-------------------------------
Getting back to the scenario....

Now, it is *very* unlikely that lots of forms or even a form with lots of
controls would lead to problems with stack space since the controls are not
created from each other -- they have to be separately allocated. You can
have out of memory issues but that is really referring to the heap, not the
stack.


--
MichKa [MS]
NLS Collation/Locale/Keyboard Development
Globalization Infrastructure and Font Technologies

This posting is provided "AS IS" with
no warranties, and confers no rights.
 
Michael \(michka\) Kaplan said:
Moving away from Access for a moment for the backstory....
Click to expand...

Thanks. Always interesting to learn more about what happens behind the scenes.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
 
Thanks to all who have answered my questions. Your answers have been
extremely useful and I've learnt things that I doubt I'd ever find in books
(and I've tried pretty hard...)

I'll try out some of the suggestions tomorrow and will reply with my hotmail
login (can't use NNTP through the firewall at work for my ISP).

Cheers
Jim
 
Jim, I still feel that your interest in stack issues, will not help you
solve your problem. The reason why the Access books do not explain the
stack, is - IMO - that it is something which you seldom, if ever, need to
know anything about, when writing Access VBA.

Your problem sounds much more like a db corruption problem, or a software
install problem, to me. The KB article was interesting, but I predict that
nothing in there, will solve your problem - unless you have an unbounded
recursion (which I suggested before).

Let us know if/when/how you eventually solve it :-)

Cheers,
TC
 
Back
Top