gtephx (Mike Pflueger) (05/15/91)
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
gtephx (Mike Pflueger) (05/16/91)
In article <1991May14.183620.7561@...!asuvax!gtephx>, pfluegerm@...!asuvax!gtephx (Mike Pflueger) writes: > 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. [ stuff deleted ] > 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. Well, I found it. My fault I guess - when I switched from 2.03 to 3.01 and TP 3.01 rebuilt my project, I didn't replace the Interface.lib and Runtime.lib files in the project. I incorrectly assumed that TP really WAS converting the project. When I replaced these two files in my project with the 3.01 versions and rebuilt the application, everything worked fine. Now my question is - if TP is converting the project for a new version, why isn't it smart enough to replace libraries in the project with the new versions? 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
siegel@world.std.com (Rich Siegel) (05/17/91)
In article <1991May15.200222.12702@...!asuvax!gtephx> pfluegerm@...!asuvax!gtephx (Mike Pflueger) writes: > >Well, I found it. My fault I guess - when I switched from 2.03 to 3.01 >and TP 3.01 rebuilt my project, I didn't replace the Interface.lib and >Runtime.lib files in the project. I incorrectly assumed that TP really >WAS converting the project. > >When I replaced these two files in my project with the 3.01 versions >and rebuilt the application, everything worked fine. > >Now my question is - if TP is converting the project for a new version, >why isn't it smart enough to replace libraries in the project with the >new versions? The project document is merely a list of the files referenced by the project, and not the files themselves. The library files themselves exist on disk as separate files, not in the project. R. -- ----------------------------------------------------------------------- Rich Siegel Internet: siegel@world.std.com Software Engineer Applelink: SIEGEL Symantec Languages Group
siegel@world.std.com (Rich Siegel) (05/17/91)
In article <1991May15.200222.12702@...!asuvax!gtephx> pfluegerm@...!asuvax!gtephx (Mike Pflueger) writes: > >Well, I found it. My fault I guess - when I switched from 2.03 to 3.01 >and TP 3.01 rebuilt my project, I didn't replace the Interface.lib and >Runtime.lib files in the project. I incorrectly assumed that TP really >WAS converting the project. > >When I replaced these two files in my project with the 3.01 versions >and rebuilt the application, everything worked fine. > >Now my question is - if TP is converting the project for a new version, >why isn't it smart enough to replace libraries in the project with the >new versions? > There is a section of the THINK Pascal 3.0 user's manual. Verbatim, it is as follows (page 15-16, for those of you who want to read along): REMOVING YOUR OLD VERSION OF THINK Pascal If you're upgrading from an old version of THINK Pascal, you need to remove it before installing THINK Pascal 3.0. REMOVAL INSTRUCTIONS Make sure you have a backup copy of your previous version of THINK Pascal. You may need it if you have any trouble with THINK Pascal 3.0. Then remove your old THINK Pascal Folder from your hard disk. You should delete at least these files: - THINK Pascal (the application) - Interface.Lib - Runtime.Lib - Interfaces folder - Libraries folder NOTE: don't delete any projects or libraries that you created or modified. R. -- ----------------------------------------------------------------------- Rich Siegel Internet: siegel@world.std.com Software Engineer Applelink: SIEGEL Symantec Languages Group