Adding Breakpoint causes Paradox to close

I have a working form that runs properly, both as a .FSL inside full Paradox, and as a .FDL in Runtime.  When I am running in full Paradox, I open a method and set a breakpoint.  When I hit the 'Run' icon, one of two things happens. 

1 - Paradox shuts down

2 - I get a strange error saying I've tried tor eference an object that doesn't exist.  The object name listed in the error message is corrupted.  I have an object similarly named, but the error message shows the last four characters of the name has been replaced with some unprintable characters.

I am running Paradox 10.0.0.719.

I have about a dozen forms in the application.  The problem form provides the main menu for my application.  It has three pages in it, one for configuration options, one for the menu, and one for entering test details.  It is the only form that shows this behavior.  All others run with breakpoints and can be debugged normally.  I do have some fairly complex methods in this one, but I've tried to move many into an objectPal library.  Total form file size is 512 kB.

Any ideas would be greatly appreciated.  I've resorted to putting 'printf' style statements (writing into a log file) throughout the methods to help me debug things.

just this form? anywhere in the form, or just certain places? in older backups? can you isolate when/where the behavior started?

Steven Green
Senior Software Engineer
Paradox Support Specialist DOS/WIN

Steven,

So far, I've not had time to really dig into things.  Since the form runs properly (as far as I can tell) without breakpoints, I've been moving forward with development and testing as this application needs to ship soon. 

I may have found a backup of the form that allows breakpoints.  I'll start working through it and the new version, adding methods piece by piece, to see if I can isolate what triggers the problem.  

When I try to set the breakpoint, and the error is displayed, if I then save the form, whatever corruption has occurred gets saved so the form is then completely unusable when I reload it.

Some additional information.  Starting with my backup form, I'm able to set breakpoints.  I'm starting to add the changes and new methods to bring it up to date, attempting to run with each addition.  If it runs with a breakpoint, I'm saving it.

I got to a point where I added a method, and received a General Protection Violation.  I re-started and added just the method declaration and variable definitions, with no code in the method itself.  Still go the GPV. 

I then added just the declaration and a variable block, but commented out my variables.  No errors at that point.  One by one I uncommented a variable.  The first 2 were successful, the third caused the GPV. 

It doesn't matter which variable I add, I get a GPV once I add another variable.  

Is there some limit to the number of local (or total) variables a form can handle?  This form does have a bunch.

Now, I'm cleaning up my code, removing variables and comments that are no longer needed, in the attempt to lower, not only my variable count, but my overall form size (my .fsl file is just over 500 kB).

the size limit is a meg.. not aware of what, if any, the var limit is.. what do you call "a bunch" ? :-)

you found a spot in time where it works, but the file might already been hosed.. try again with an older one.. there are no rules here.. I have had to re-create forms from scratch

Steven Green
Senior Software Engineer
Paradox Support Specialist DOS/WIN

Any ideas on how the form gets corrupted to begin with?  Something I can attempt to avoid?

Also, when you say you've had to rebuild forms from scratch, does that mean completely from scratch, or can you start with a new form and copy elements into it from the corrupted form?

something to avoid? nothing that we know of.. computers aren't perfect.. stuff happens

copy/paste? yes, that's what I've done.. I had to re-create a very complex form last year, for a client.. one piece at a time, test it, move on.. never found a specific piece that would fail.. eventually, it was all done, and I could finally make changes that they'd needed for several years

Steven Green
Senior Software Engineer
Paradox Support Specialist DOS/WIN