Path: utzoo!attcan!uunet!lll-winken!xanth!mcnc!kk
From: kk@mcnc.org (Krzysztof Kozminski)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Standard File and Desk Accessories
Message-ID: <1241@speedy.mcnc.org>
Date: 8 Jun 89 14:50:20 GMT
References: <50967@tut.cis.ohio-state.edu> <7547@hoptoad.uucp> <4972@umd5.umd.edu> <51276@tut.cis.ohio-state.edu> <2015@husc6.harvard.edu>
Reply-To: kk@mcnc.org.UUCP (Krzysztof Kozminski)
Organization: Microelectronics Center of NC; RTP, NC
Lines: 74

In article <2015@husc6.harvard.edu> siegel@endor.UUCP (Rich Siegel) writes:
>In article <51276@tut.cis.ohio-state.edu> Todd A Hitt <thitt@cis.ohio-state.edu> writes:
>> [adding a resource (!!) to a resource file to hold storage]
>
>	Yeeeech. [followed by bashing of the idea, admittedly deserved]

OK, OK, so I won't suggest any more ideas generated at 3 am ... but it
worked perfectly in that at least Todd got some sound suggestions from
Ben Cranston.  I am not sure if Rich's solution is applicable - remember
that Todd has mentioned that for some reasons he cannot use global variables.

:-):-):-):-):-):-):-):-)
BTW, an idea that I had at 3:15 am was to use the NULL location:
	*((Handle*) 0L) = HStorage;
	
Why not? All applications should avoid writing into NULL location, so
your data should be perfectly safe there (However, standard file dlogs
used to dump 0x00FFFFFF into *NULL in older Sysytem versions)
:-):-):-):-):-):-):-):-)

For the record, my full letter to Todd included an outline of another technique
(using refCon in an existing, privately owned CNTL resource that is already
in memory - so that it wouldn't cause any problems that AddResource is
likely to create) - similar to Ben Cranston's idea of extending the dialog
item list.  (I use it to pass data to a custom CDEF that is invoked from a
CNTL that is appended to the DITL number -3999 after having increased the
window size in DLOG number -3999 to show my extra CNTL)

Now, modifying a system DITL in memory is also not that great idea (other
applications may want to use it) and having a duplicated, modified DITL 
in the application calls for updates each time Apple changes theirs... so
my application compares its DITL with the system DITL upon startup and updates
the modified DITL if necessary (and DLOG, too).

Any holes or potential problems there?

------------------------------
Now my turn in idea - bashing:

>An alternate solution involves some assembly language, and works something like
>this:
>	Define a 4-byte spot in your code where you can store a handle.

Yeeechh.  A "spot in your code"? Tim Maroney also suggested writing into
the code space ... Is self-modifying code OK nowadays? Anyway, I have this
impression that a spot in memory, the address of which is known to more
than one routine, is called a global variable ...

> [Two procedures in assembly]

It seems to me that what Rich wrote is essentially equivalent to the following:

	Handle HStorage;

	SaveAway(h) Handle h;
	{ HStorage = h; }

	GetBack(hp) Handle *hp;
	{ *hp = Hstorage; }

That's *not* the answer to the original question (no globals, remember?).
Perhaps this modification would work:

	SaveAndGetBack(saveIt, hp)
	Boolean saveIt; Handle *hp;
	{ static Handle HStorage;
	  if (saveIt) HStorage = *hp;
	  else *hp = HStorage;
	}

but then, if a development system does not allow globals, then why would it
allow static variables?

KK