George Strang

Best of luck,
Brian

I am surprised that this subject does not come up more often.  I am certain
that other developers must be seeing this behavior because it is so easy to
reproduce.  I came across it for the first time when I had forms with
buttons that opened and waited on other forms.  Since each form was being
waited on, the functions that opened the child forms were not completing
and so the stack was extending as further generations of child forms were
being opened.  I found that I could only nest forms about two to four
levels deep before I got the stack overflow message.

The bad news is that I know of no solution.  The good news is that there
are some workarounds.  I have spent a lot of time trying to solve this
problem and have never gotten a satisfactory fix to work.  Instead, I have
had to write a lot of code that avoids the problem by operating in a
non-intuitive manner.  As a side note, I would estimate that 20% of the
ObjectPAL code that I write is to workaround deficiencies such as this
stack limitation.

Here's what I have learned:

1. Borland tech support will recommend a variety of fixes, NONE OF WHICH
   WORK.  So far, they have suggested:
   a. Increasing the STACKS parameters in config.sys.
   b. Playing with the IDAPI buffer size settings.

   Don't bother trying any of these.  The experiment described in the next
   item shows absolutely no correlation between these settings and the
   amount of Paradox stack memory.

2. The size of a Paradox stack frame seems to be related to the size of the
   form, among other things.  This is non-intuitive.  I would expect that a
   stack frame's size would be a function of the size of the function's
   arguments and local variables.

   To prove this conjecture, create a simple form having one button that
   opens the same form again.  Run the form and count how many times you
   can click the button in each new opening of the form.  Eventually, you
   will get a stack overflow message.  Now add objects and code to the form
   and run it again.  You will be able to click the button far fewer times
   before getting the overflow message.

3. Each version of PdoxWin has had this same problem, and I have used every
   version since 1.0.

4. To work around the problem, I no longer directly open a child form and
   wait on it.  Instead, I set up all the information needed to open the
   child form (form name, etc.), then I schedule the opening of the form to
   occur during the next idle time by posting a user action.  The handler
   for the user action opens the child form and waits on it.

   This workaround allows the stack to get cleaned up somewhat, since an
   idle condition won't occur until the current non-waiting code has
   completed.  Nested function calls can therefore complete before the
   child form is opened.

   Using this workaround, I have been able to increase the number of nested
   forms that can be opened to between five and eight (depending on the
   size of the nested forms).

I don't mind that Paradox has its own stack, but I do wish that Borland
would give the developer a way to set its size.

--Dan Milliron

2) Try place your code in a procedure.

3) Don't bother adding more breakpoints or stacks to your windows
setup, as that doesnt help paradox at all.

4) Refer to all items directly if you can, and in instances where your
calculations are nested deeply (x+(3*y/(8*3)) try to create interim
values.  Also, declare all the variables in yourmethod or procedure.

5) Throw a sleep in if your sorting or doing form opens.  it REALLY
helps.

6) NEVER resynce a form just after it's been open even if your using a
Sleep statement.

Try these out.  If you have some more specific information, i'd be
glad to give you a bit more help.

Joel Ostapowcih

BC>>been done previously and doesn't have to go through all the code.  Before
  >>that, I was getting a stack overflow msg saying " IF statements nested too
  >>deeply", but I managed to get them down to 3 deep at the maximum, and then
  >>the msg changed to the one above.  Nevertheless, the stack is still
  >>overflowing.  If I run it in the de{*filter*} everthing executes fine.  Is ther
  >>some way to increase the stack length in Object Pal??  Can someone help me
  >>with this annoying problem.  Any and all advise would be much appreciated!
  >>Thanks in advance.
  >>
  >>George Strang

BC>We had a problem like that once.  It's been a while, but for us it was havin
  >too much code on the open and arrive methods.  Once we moved it into custon
  >methods, the problem went away.  (This makes some since, because you are
  >probably declaring variable EVERY TIME the form::action is called.  If you
  >call a custom method and only access that code when necessary you may have
  >better luck.)

I had the same problem and came to the same conclusion as you did to
it's cause.  The only difference is I fixed it by putting a dodefault
before any of my own code in the form's open or arrive methods.  I
think (in a rather warped sense) that my dodefault placement achieves
the same result as your moving things to custom methods as far as the
stack is concerned.  Anyway,  it cures the stack overflow messages
because I haven't seen one in a long time.

 * 1st 2.00b #3378 *