Path: utzoo!mnetor!uunet!husc6!endor!olson
From: olson@endor.harvard.edu (Eric K. Olson)
Newsgroups: comp.sys.mac
Subject: Re: Question about WDEF routines.
Message-ID: <3714@husc6.harvard.edu>
Date: 5 Jan 88 23:10:53 GMT
References: <7595@sunybcs.UUCP> <7126@apple.UUCP> <3709@husc6.harvard.edu> <7132@apple.UUCP>
Sender: news@husc6.harvard.edu
Reply-To: olson@endor.UUCP (Eric K. Olson)
Distribution: na
Organization: Lexington Software Design
Lines: 53

Folks, I must apoligize:

In a recent article Larry Rosenstein writes:
>In article <3709@husc6.harvard.edu> olson@endor.UUCP (Eric K. Olson) writes:
>>
>>If you have a compiler that can specify code segments (LSC, for example),
>>move the WDEF code into a segment of its own and do a GetResource('CODE',id)
>>and a DetachResource of the returned handle.  This gives you a private
>>copy of the code, referenced as a handle.  Detaching it ensures that it will
>>not be mucked with by the segment loader or resource manager.  You may also
>>need to HNoPurge the handle, depending on how it is flagged in the resource
>>file.

I'm not sure what drugs I was on when I wrote this.  I may have tried it,
but it certainly didn't work.  The reason below is good enough for me:

>There is supposed to be a 4 byte segment header in each CODE segment
>(indicating the location and number of jump table entries).  Do you do
>something special to get around this?

No, I probably gave up on that idea when it crashed....

In fact, I wasn't even testing a WDEF when I tried to incorporate a 
definition procedure's code into the test application.  I was writing
a CDEF!!!  (I wrote a WDEF just before the CDEF, so you can understand
my confusion with myself).  [BTW, CDEFs should be tested the same way
as WDEFs-- the way Larry originally suggested, with a 6-byte jump-to-the-
correct-spot handle].

I have erred.  In correcting the correct, I have erred twice.  In not
recognizing my error, I have erred three times.  I must apply my prime
directive.  Sterilize.  Sterilize.  Ste...ri...lizzzzz..... [Star Trek]

In fact, what I did is this [incorrect technique-- don't use this]:

	GetDItem(theDlg,1,&dType,&dHandle,&dRect);
	control=dHandle;
	
	cdefptr=&cdef;
	(*control)->contrlDefProc=&cdefptr;
	
cdefptr is a global Ptr.  This worked [really!], but not for any good
reason.  In fact, any memory manager calls applied to this "handle" (it's
not a handle) will fail miserably.  I just got lucky.

*Sigh*.  Sorry for the confusion, everybody.

-Eric


                      (defun maybe (x) (maybe (not x)))
Eric K. Olson     olson@endor.harvard.edu     harvard!endor!olson     D0760
   (Name)                (ArpaNet)                 (UseNet)        (AppleLink)