ADVERTISEMENT
|
|
Think Pascal 4
Don Sawtelle
Having just expressed August's final proof back to Bill Anderson-lacking this page, of course-I have only to write this column, then it's on to October. Instead of writing an August issue overview, I'll describe a small useful workaround for failure handling with Think Pascal 4 (announced August 6th, and now shipping).
Just What you've been waiting for…
Think Pascal 4 runs under System 7 in both 24- and 32-bit modes, and works fine with virtual memory. It has all the headers required for writing System 7-savvy applications, and supports far code, making it possible to create applications that require up to 256k of jump table space. You can find out more about these and other new features by calling Symantec (617-275-4800)-or better yet,
just order the upgrade. Oh, and project updates
have been optimized; MacApp compiles noticeably faster.
…and Now 99% reliable
Think Pascal 4 is much more reliable when working with large MacApp applications than was Think Pascal 3. Think Pascal 3 had a serious flaw with respect to MacApp; if anything called Failure while running in the Think environment, and some of the routines on the stack at the time were compiled with the D option in the project window checked (so that you could source-debug them), Think Pascal was likely to crash. It would sometimes crash right away, and sometimes later, when you were no longer even thinking of your past failures. And projects could sometimes get corrupted, causing nasty problems that didn't go away until you removed the code from the project and rebuilt, or created a new project from scratch.
Because of all this, life was difficult when debugging anything with Think Pascal 3 that involved failure handling. The most useful technique for debugging failures-setting a stop sign at the beginning of the Failure procedure, so that you can see the context of the error before MacApp's failure handling cuts back the stack and displays the error dialog-caused Think Pascal 3 to crash when a failure occurred. I find it convenient to write code that uses failure handling even for recovery from soft (non-catastrophic) errors, so this was a real problem for me.
With the new release, Think Pascal 4 provides a couple of replacements for the MacApp failure library that you can use when debugging in the Think environment-one for use with the MacApp debugger, one for without. These libraries call a special trap that causes the Think Pascal debugging
environment to do the cleanup it needs to for each routine that was on the stack at the time of a failure.
In my experience, with these special failure libraries, Think Pascal 4 is now almost 100% reliable. Most mysterious crashes of the Think environment eventually turn out to be my own runaway code trashing something that's none of its business. (Oh, for a protected memory space!) There are only two limitations: (1) you have to compile your entire application, including MacApp, with the Think debugging option on, because the special failure library isn't smart about not calling the Think cleanup code if a routine on the stack wasn't compiled with the Think debugging option; and (2) for some reason, which I hope Symantec technical support can eventually explain, a failure during application initialization(IMyApplication) still crashes Think Pascal, if you're using the special failure libraries.
The first limitation isn't serious unless your code runs too slowly when the entire application is compiled with Think debugging on. And it's safe to compile units that won't fail, and that don't call any routines which could fail, without Think debugging.
The second limitation seems to be the last remaining bit of Think Pascal's former unreliability that developers have lived with for so long. If your application does nothing complex during initialization, and your code doesn't have any bugs, you may not encounter the problem. I have an application that looks for devices during IMyApplication, and that uses failure handling as a way to gracefully handle their absence; if you do something like this, you'll be sure to repeatedly encounter the hard crash.
I've come up with a simple workaround. It's kind of odd, but it seems to circumvent the problem, and not cause any new ones, either.
How to keep the special failure library
from crashing Think Pascal 4
First, make sure you have a correct TMyApplication.Initialize method that puts your application object in a state where it can be safely freed if something goes wrong. Actually, nothing will go wrong-famous last words-but just in case. Then, in your MMyApplication.p unit, call IApplication instead of IMyApplication. Also, change IMyApplication so that it doesn't call IApplication. Add a boolean to TMyApplication called fPostInitialize, set it to false in TMyApplication.Initialize, and override MacApp's PollEvent as shown in the PollEvent listing.
With these changes, the significant initialization code for your application-the code that might fail-won't execute until MacApp's event handling loop runs for the first time. Thus you'll avoid the possibility of failure at a time when it could crash Think Pascal.
Do be sure to contain these changes within {$IFC} directives, so that it's easy to build your standalone application without them. This workaround is a hack that's just intended for using during debugging; you don't want it in your final code! n
|
Slashdot
Digg
del.icio.us
reddit
newsvine
Y! MyWeb
