alexis@ccnysci.UUCP (Alexis Rosen) (01/03/89)
I got Think Pascal 2.0 over a month ago, and it looked very nice. It is, overall, a great improvement over LSP 1.11, except- it doesn't work! I had heard several people complain about bugs, but I was very disappointed to find one on the very first program I tried. The problem: When you want to create your own dialog templates for the SFGetFile and SFPutFile routines, you can't. It always uses the DLOG -4000 (and the other std. file resources) that it finds in the system file, regardless of what you put in your resource file. If you call SFPutFile with a custom DlgHook you will likely get a variety of bus errors or other strange errors that will leave you scratching you head for a while. You can even crash your Mac. Of course everything worked properly in LSP 1.11 and everything works right when I run the compiled app. So all I lose is my ability to debug the damn thing. Truth-in-bitching: I'm not being fair. Mostly, LSP 2.0 seems to be a damn good product. Saying LSP "doesn't work" is a tremendous overstatement... but I'm tremendously ticked off right now so screw it. Alexis Rosen alexis@ccnysci.uucp
leonardr@uxe.cso.uiuc.edu (01/04/89)
alexis@ccnysci.UUCP(Alexis Rosen) wrotes in comp.sys.mac.programmer >The problem: When you want to create your own dialog templates for the >SFGetFile and SFPutFile routines, you can't. It always uses the DLOG >-4000 (and the other std. file resources) that it finds in the system >file, regardless of what you put in your resource file. If you call >SFPutFile with a custom DlgHook you will likely get a variety of bus >errors or other strange errors that will leave you scratching you head >for a while. You can even crash your Mac. Of course everything worked >properly in LSP 1.11 and everything works right when I run the compiled >app. So all I lose is my ability to debug the damn thing. > I hate to disagree with you Alexis, but I just did this the other day using LSP 2.0 and had NO problems!! If you could post your code, maybe we can find something there, but I did a SFPGetFile with my own custom filter and dlgHooks and it worked beautifully (it didn't work when I put it into MPW though, but that was MY fault!) One other thing to check, are you sure that you have the resource file with your SFdialog setup in teh Run Options dialog?? +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + AppleLink: D0025 + + + + +---------------------------------+-----------------------------------+
siegel@endor.harvard.edu (Rich Siegel) (01/05/89)
In article <1112@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: >The problem: When you want to create your own dialog templates for the >SFGetFile and SFPutFile routines, you can't. It always uses the DLOG >-4000 (and the other std. file resources) that it finds in the system *FLAME ON* Why do you feel honor-bound to blame the environment for your own stupid mistakes? In Inside Macintosh, Volume 1, Chapter 20 (The Standard File Package), it explains the following: - if you want to use a custome dialog box with SFGetFile or SFPutFile, place it in your resource file with the SAME resource ID as the standard dialogs, and pass in a custom dialog hook. - if you want to use a custom dialog box that has a DIFFERENT resource id than the standard boxes, you need to use SFPGetFile and SFPPutFile (note the extra "P" after SF). RTFM before you start pointing fingers. *FLAME OFF* --Rich Rich Siegel Staff Software Developer THINK Technologies Division, Symantec Corp. Internet: siegel@endor.harvard.edu UUCP: ..harvard!endor!siegel Phone: (617) 275-4800 x305 Any opinions stated in this article do not necessarily reflect the views or policies of Symantec Corporation or its employees.
alexis@ccnysci.UUCP (Alexis Rosen) (01/06/89)
In article <919@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >In article <1112@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: > >>The problem: When you want to create your own dialog templates for the >>SFGetFile and SFPutFile routines, you can't. It always uses the DLOG >>-4000 (and the other std. file resources) that it finds in the system > > *FLAME ON* > > Why do you feel honor-bound to blame the environment for your own >stupid mistakes? In Inside Macintosh, Volume 1, Chapter 20 (The Standard File >Package), it explains the following: > [etc., explains difference between SFGetFile & SFPGetFile] > RTFM before you start pointing fingers. Rich, I may be making a mistake, but it sure isn't that one. RTFMessage... I am using the same Resource IDs as are in the system file (-3999 and -4000) for my modified SFGetFile & SFPutFile. This strategy works just fine in LSP 1.0. Furthermore, it works just fine in *LSP 2.0* once I compile it down to a real app. So what's going on??? Leonard Rosenthal suggests I'm not telling LSP to look in my resource file, but I am. He also says: > I hate to disagree with you Alexis, but I just did this the other day using >LSP 2.0 and had NO problems!! If you could post your code, maybe we can find >something there, but I did a SFPGetFile with my own custom filter and dlgHooks >and it worked beautifully (it didn't work when I put it into MPW though, but >that was MY fault!) I'm glad it worked; you don't need this headache, however small it is in the general scheme of things. My guess is that it worked for you because you are using the 'P' versions of the Standard File Package. It seems to me that what is happening here is that LSP 2.0 will use the attached resource file, but the system file seems to be in the search path before the attached resfile. Therefore Leonard's code works because his resources' numbers don't conflict with any in the system file, whereas mine do. This is just a theory, though, I haven't tested it. ( I don't need lectures on programming style. I know the 'SFP' routines are better. But I wrote this code a long time ago and I didn't want to hack on it any in order to get it to compile. ) In the meantime I'm using LSP to write XCMDs and XFCNs for FoxBase. It works very well... FoxBase implements all but two of the HyperCard callback functions. They did a very nice job. Alexis Rosen alexis@ccnysci.uucp
leonardr@uxe.cso.uiuc.edu (01/08/89)
alexis@ccnysci.UUCP(Alexis Rosen) writes in comp.sys.mac.programmer >In article <919@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes: >>In article <1112@ccnysci.UUCP> alexis@ccnysci.UUCP (Alexis Rosen) writes: >> >>[All sorts of flames, etc. deleted!] > >Rich, I may be making a mistake, but it sure isn't that one. RTFMessage... >I am using the same Resource IDs as are in the system file (-3999 and -4000) >for my modified SFGetFile & SFPutFile. This strategy works just fine in LSP >1.0. Furthermore, it works just fine in *LSP 2.0* once I compile it down to >a real app. > >[More discussion about my suggestions] > >It seems to me that what is happening here is that LSP 2.0 will use the >attached resource file, but the system file seems to be in the search path >before the attached resfile. Therefore Leonard's code works because his >resources' numbers don't conflict with any in the system file, whereas mine >do. This is just a theory, though, I haven't tested it. > Seems to be that that is a very possible suggestion, and someone might want to break out TMON and check it out to verify it. Though that would be weird since it would also pt the System before LSP as well. Is it possible that you do a UseResFile(0) and forgot to reset it?? >( I don't need lectures on programming style. I know the 'SFP' routines are > better. But I wrote this code a long time ago and I didn't want to hack on > it any in order to get it to compile. ) > Using SFPGet and SFPPut in place of the standar ones are EASY. All you do is call them instead and give it two new params, the dialog's ID# and a filter proc for the dialog. NO BFD... Considering that I have it on good authority that Standard File is going to change BIG TIME sometime soon (don't ask me when, though..) I would suggest that for possible future compatibility you consider spending the time to do SFP's.. +---------------------------------+-----------------------------------+ + + Any thing I say may be taken as + + Leonard Rosenthol + fact, then again you might decide+ + President, LazerWare, inc. + that it really isn't, so you + + + never know, do you?? + + leonardr@uxe.cso.uiuc.edu + + + GEnie: MACgician + MacNET: MACgician + + Delphi: MACgician + AppleLink: D0025 + + + + +---------------------------------+-----------------------------------+
alexis@ccnysci.UUCP (Alexis Rosen) (01/11/89)
In article <226000043@uxe.cso.uiuc.edu> leonardr@uxe.cso.uiuc.edu writes: > >alexis@ccnysci.UUCP(Alexis Rosen) writes in comp.sys.mac.programmer >>I am using the same Resource IDs as are in the system file (-3999 and -4000) >>for my modified SFGetFile & SFPutFile. This strategy works just fine in LSP >>1.0. Furthermore, it works just fine in *LSP 2.0* once I compile it down to >>a real app. >> >>[More discussion about my suggestions] >> >>It seems to me that what is happening here is that LSP 2.0 will use the >>attached resource file, but the system file seems to be in the search path >>before the attached resfile. Therefore Leonard's code works because his >>resources' numbers don't conflict with any in the system file, whereas mine >>do. This is just a theory, though, I haven't tested it. >> > Seems to be that that is a very possible suggestion, and someone might >want to break out TMON and check it out to verify it. Though that would >be weird since it would also pt the System before LSP as well. Is it possible >that you do a UseResFile(0) and forgot to reset it?? Well, I just checked, and LSP is *definitely* not making that mistake (to be honest, I can't imagine how one would go about making that kind of mistake anyway). And no, I'm not doing UseResFile(0) or anything like that. If I were, how could it work when it was compiled? I think the real point here is that the LSP environment is not successfully mimicing the real environment in this unusual situation. I just can't figure out *why* it would choose to break in this particular way. Naturally they can't be 100% perfect, so maybe if we figure out why it breaks here we will have some useful insight on other potential problem situations as well. I would still like to know if anyone can reproduce this on their machine. I've tried it on two Mac IIs with identical results. > Using SFPGet and SFPPut in place of the standar ones are EASY. All you >do is call them instead and give it two new params, the dialog's ID# and >a filter proc for the dialog. NO BFD... Yes, I know, I just didn't want to change anything. Of course, all my recent code uses the P versions. Alexis Rosen alexis@ccnysci.uucp