Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!usc!cs.utexas.edu!asuvax!hrc!gtephx!pfluegerm
From: pfluegerm@...!asuvax!gtephx (Mike Pflueger)
Newsgroups: comp.sys.mac.programmer
Subject: THINK Pascal bug? (was Re: SFGetFile Problems in THINK Pascal 3.0.1)
Message-ID: <1991May14.183620.7561@...!asuvax!gtephx>
Date: 14 May 91 18:36:20 GMT
References: <5831@ns-mx.uiowa.edu> <1991May3.182555.10441@...!asuvax!gtephx> <1991May5.155320.29525@ulrik.uio.no>
Organization: AG Communication Systems - Phoenix, AZ
Lines: 82

In article <1991May5.155320.29525@ulrik.uio.no>, kmork@ulrik.uio.no (Knut Mork) writes:
> Try to avoid using "reset" commands and other high-level pascal file managing
> commands in mac applications.  If you do, make sure of the following things:
> 1) You use "runtime.lib" and NOT "mruntime.lib"
> 2) THE FILE YOU CHOOSE IN THE SFGETFILE BOX IS IN THE SAME FOLDER AS THE
> APPLICATION!!!!!
> 
> This Is IMPORTANT!! Reset and Rewrite have no searching capabilities.  They
> just check the folder you're in for the files.
> 
> So if you need files available from other folders, use the File Manager!
> I'd be more than happy to help you all with it, if you need it.
> 
> --Knut Mork, kmork@ulrik.uio.no

Just got this, our feed site has been slow or down (the response was
posted 5/5 and I just saw it on 5/14).  Thanks for the reply.

My original posting refers to a problem I am encountering in my application
when compiled with THINK Pascal 3.02 which happens to be shortly after an
SFGetFile (which another netter was posting about).  If I say OK, my program
then moves to the folder containing the selected file, then does a

    "reset(file, filename);"

to open the file read-only. Interactively, running within TP 3.01, it works
OK.  When built/saved and run as a stand-alone application, I get a "runtime
error" on the "reset".  It was developed and worked under TP 2.03, including
the stand-alone "built as application" version.  Just recompiling under 3.01
introduced the problem. (I have since done the 3.02 upgrade, and the problem
still exists.)  I tried building with all the options (Debug, Names, oVerflow,
Range) turned off for that piece of code - problem still occurs.

And yes, the file exists and all.  I went back and ran the 2.03-compiled
version of my program (opening the same file and executing the same code,
of course) and it works OK.  And as I said, it works running within THINK
Pascal 3.01/3.02.

I have no intentions of porting my application to another compiler or
distributing the source, so I used the high level "reset".  If I ever
do port, I'll rewrite it as necessary.  For now the "reset" is easier,
so why not use it?  (other than this problem, of course)

I AM using the runtime.lib, not the micro-runtime.lib.

I am aware that SFGetFile does not search for the file.  I should have
been more explicit. After the SFGetFile, I make sure that I have switched
to the correct folder (using PBHSetVol) before doing the reset.  Again, it
works OK except for the 3.0x built/saved stand-alone application.  

What I HAVE found by debugging in MacsBug is that the compiler is inserting
some code to read (GetResource) the 'LSP ' resources numbered 2001 and 2002
from my applications' resource fork.  I assume these point to TP library
routines (e.g. the "reset") or something.  Anyhow, the requested resource
doesn't exist (nil pointer) which the code handles by explicitly breaking
into the debugger (with _DebugStr), followed by an _ExitToShell.  TP *did*
build an 'LSP ' resource 2000 into my application.

The THINK Pascal 3.0x itself contains 'LSP ' resource numbers 2000 and 2001.
Thinking maybe the compiler was incrementing something it shouldn't, I tried
patching the code to read in 2000 and 2001 instead of 2001/20002.  Didn't
help.  Tried various combinations of this, still of no help.

About the only thing I haven't done is look in TP 2.03 to see which 'LSP '
resources it contains.  Maybe there was a bug in rebuilding the project
when I switched from 2.03 to 3.01.

I've also emailed Rich Seigel, but haven't gotten a response.  With the
mail system we have here, it's entirely possible it got lost.  Rich, are
you there?  I may also have missed a reply since, as I said earlier, our
news feed site has been slow or down.  If so, I apologize.

Thanks in advance for any help!

Mike


-- 
Mike Pflueger @ AG Communication Systems (formerly GTE Comm. Sys.), Phoenix, AZ
  UUCP: {...!ames!ncar!noao!asuvax | uunet!hrc | att}!gtephx!pfluegerm
  Work: 602-582-7049        FAX: 602-582-7624     Home: 602-439-1978
Packet: WD8KPZ @ KB7TV.AZ.USA.NA  Internet: gtephx!pfluegerm@asuvax.eas.asu.edu