Stack Overflow Msgs ............AAAARRRRRGGGGGHHHH!!!!! 
Author Message
 Stack Overflow Msgs ............AAAARRRRRGGGGGHHHH!!!!!

I'm developing an application in PDOXWIN 5.0 and one of my form methods has a
lot of code in it.  It's an "action" method in the form itself, and executes
when switching between records.  This method has a lot of code for
calculations in it (several hundred lines), but it only goes through all of
the code if the calculations have not been done previously, otherwise it does
a check and then returns.  I'm getting a stack overflow msg saying that my
"methods or procedures are nested too deeply", even when the calculations have
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 I
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 there
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



Sat, 03 Jan 1998 03:00:00 GMT
 Stack Overflow Msgs ............AAAARRRRRGGGGGHHHH!!!!!


Quote:

>I'm developing an application in PDOXWIN 5.0 and one of my form methods has a
>lot of code in it.  It's an "action" method in the form itself, and executes
>when switching between records.  This method has a lot of code for
>calculations in it (several hundred lines), but it only goes through all of
>the code if the calculations have not been done previously, otherwise it does
>a check and then returns.  I'm getting a stack overflow msg saying that my
>"methods or procedures are nested too deeply", even when the calculations have
>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 I
>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 there
>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

We had a problem like that once.  It's been a while, but for us it was having
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.)

Best of luck,
Brian



Mon, 05 Jan 1998 03:00:00 GMT
 Stack Overflow Msgs ............AAAARRRRRGGGGGHHHH!!!!!
: I'm developing an application in PDOXWIN 5.0 and one of my form methods has a
: lot of code in it.  It's an "action" method in the form itself, and executes
: when switching between records.  This method has a lot of code for
: calculations in it (several hundred lines), but it only goes through all of
: the code if the calculations have not been done previously, otherwise it does
: a check and then returns.  I'm getting a stack overflow msg saying that my
: "methods or procedures are nested too deeply", even when the calculations have
: 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 I
: 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 there
: 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.

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



Tue, 06 Jan 1998 03:00:00 GMT
 Stack Overflow Msgs ............AAAARRRRRGGGGGHHHH!!!!!

Quote:

>I'm developing an application in PDOXWIN 5.0 and one of my form methods has a
>lot of code in it.  It's an "action" method in the form itself, and executes
>when switching between records.  This method has a lot of code for
>calculations in it (several hundred lines), but it only goes through all of
>the code if the calculations have not been done previously, otherwise it does
>a check and then returns.  I'm getting a stack overflow msg saying that my
>"methods or procedures are nested too deeply", even when the calculations have
>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 I
>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 there
>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

1.) Never put code in the open method of a form.  Not only does this
lend to instabilities, but it also slows down your form opens
SUBSTANTIALLY, as it has to run the IF..THEN loop for EVERY object on
the form.  So if the form has a LOT of objects, dont use the forms
OPEN method.  The action method is a safe one to use, so that's not
likely the cause of your problem.

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



Wed, 07 Jan 1998 03:00:00 GMT
 Stack Overflow Msgs ............AAAARRRRRGGGGGHHHH!!!!!

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 *



Thu, 08 Jan 1998 03:00:00 GMT
 
 [ 5 post ] 

 Relevant Pages 

1. Stack Overflow Dump not possible

2. SQLSRV32.DLL Stack Overflow !!!

3. stack overflow using very large SELECT query

4. stack Overflow Dump not possible

5. Stack Overflow in Data Transformation Services

6. Getting an Error.. stack overflow dump not possible

7. WHAT IS STACK OVERFLOW?

8. The server encountered a stack overflow during compile time

9. Stack Overflow

10. Sql server 2000 stack overflow error during compile time

11. Stack Overflow from ERRORLOG

12. upgrade hangs, causing stack overflow...


 
Powered by phpBB® Forum Software