Dan: If you are having that many levels of file depth, 30 may not be enough, try changing this setting to 50 and see what happen. I have attached a write up that Razzak posted a while back, I think it illustrates the use of QUIT TO instead of RUN, as a way to avoid deep nesting and its memory problems. Other than that, I can't think of anything else, since the forms works most of the time, it is apparently not corrupted. Javier,
Javier Valencia, PE President Valencia Technology Group, L.L.C. 14315 S. Twilight Ln., Suite #14 Olathe, KS 66062-4571 (913)829-0888 (913)649-2904 FAX > > It depends on how many RUN statements you have! It looks like you > > have too-many. > > > > When you use RUN filespec command from within a command or > > procedure file, R:BASE adds one to the nesting level for each nested > > command file. RETURN is the only way to exit command and to return > > control to the next line in the calling command file, and the nesting > > counter decreases by one. > > > > You can nest command files, such as RUN filespec, IF structures, > > WHILE loops, and SWITCH structures. The number of control > > structures that you can nest depends on the amount of memory > > available when the command or procedure file executes. > > > > You can have up to five levels of RUN execution, unless you use the > > SET FILES command to change the number of command files that > > can be open simultaneously. In other words, command file 1 can > > execute command file 2, command file 2 can execute command file 3, > > command file 3 can execute command file 4, and command file 4 can > > execute command file 5. Successive RETURN commands pass > > execution control back up through the command files. > > > > It all comes down to defining nesting levels and ... making sure to return > > control back to the originating command file. > > > > I recommend to use QUIT TO filespec command. > > > > Using the QUIT TO filespec command, there is no overhead, no nesting > > level, nor does R:BASE have to keep track of nesting levels. > > > > Using the QUIT TO filespec command, you can QUIT TO any command > > file at any level you wish and never have to worry about RETURNing to > > the last command to return control to the one command before and so > > on ... > > > > QUIT TO filespec command clears all nesting levels and resets the > > nesting level to 0. Thus, no overhead. > > > > Hope that helps to understand the logic! > > > > Have a great weekend! > > > > Very Best Regards, > > > > Razzak. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Dan Sent: Tuesday, February 18, 2003 11:58 PM To: RBASE-L Mailing List Subject: [RBASE-L] - Re: Crashing Even though this has begun happening since one of the last two patches was installed, I dont think it is a bug other than in my own programming somewhere. Something sloppy I did or something. The form itself is the form that stays open almost all day and most of our dispatching is done as a result of clicking on one of the fields and subsequently opening further forms...(sometimes as many as 10 more levels deep) This form only fails after certain moves are made then an attempt is made to exit the form. It is only exiting the form that there is trouble, That is where I am confused. The calling program has the lines (amidst hundreds of others) enter using dispatch pause 2 using "test" return When all goes right, the pause comes up, and then it continues to the appropriate calling program. When it doesn't, it closes the form, but doesn't even do the pause. As though it doesn't even know what program called it. I would never be able to send enough of the form, program, etc to RBTI to get them to be able to replicate it. I will have to just keep digging. Any other ideas on how to get trace to go far enough to get to the problem? Or, what would stop trace from getting there? Dan At 06:19 PM 2/18/2003 +0000, you wrote: > >If this issue is the result of the latest patch you should contact >RBTI. One last possibility is that your form is corrupt... you might >try deleting it and loading a fresh copy from a back-up. > >Ben > >On 18 Feb 2003, at 20:13, Dan wrote: > >> >> Ben, >> I changed the predefined exit button to use a custom eep, using the >> closewindow command. >> It behaves the same as before. >> Javier, >> I have checked every variable before the exit, and after the exit >> (actually this was where I started looking this morning, assuming I >> was probably having a variable type problem) Other than sqlstate, >> nothing is different. Dan >> >> >> At 05:10 PM 2/18/2003 +0000, you wrote: >> > >> >As an alternative, try a custom eep using "CloseWindow". It's a shot >> >in the dark, but I have a foggy recollection of problems with some >> >pre-defined eeps. >> > >> >Thanks, >> > >> >Ben >> > >> > >> >On 18 Feb 2003, at 19:14, Dan wrote: >> > >> >> >> >> There isn't an exit eep.... >> >> I am using the pre-defined exit on the button. It should just >> >> return me to ther calling program. (actually does 99% of the time >> >> unless I open more forms inside the form) Also, just changed it to >> >> edit using and no change. Dan >> >> >> >> At 03:53 PM 2/18/2003 +0000, you wrote: >> >> > >> >> >Dan, >> >> > >> >> >What does your "exit" eep look like? >> >> > >> >> >If your form only contains variables, have you tried "edit using" >> >> >vs. >> >> > "enter" >> >> > >> >> >Ben Petersen >> >> > >> >> > >> >> >On 18 Feb 2003, at 18:28, Dan wrote: >> >> > >> >> >> >> >> >> Hmmm, >> >> >> No, I have a predefined 'exit' button on the bottom of every >> >> >> form for >> >> >> consistancy. I use the NOHEADER option as often as I can. >> >> >> >> >> >> >> >> >> >> >> >> >Dan: >> >> >> >Are you exiting the form by clicking the X on the corner of the >> >> >> >form? I would suggest that you run the form using the NOIHEADER >> >> >> >option >> >> >> >> >> > >> >> >> > >> >
