Path: utzoo!attcan!uunet!lll-winken!ames!nrl-cmf!ukma!rutgers!cmcl2!ccnysci!alexis
From: alexis@ccnysci.UUCP (Alexis Rosen)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Bug in resource handling in LSP 2.0
Message-ID: <1152@ccnysci.UUCP>
Date: 10 Jan 89 17:39:25 GMT
References: <1112@ccnysci.UUCP> <226000043@uxe.cso.uiuc.edu>
Reply-To: alexis@ccnysci.UUCP (Alexis Rosen)
Organization: City College of New York
Lines: 44

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