Path: utzoo!utgpu!water!watmath!clyde!rutgers!husc6!ut-sally!brian
From: brian@ut-sally.UUCP (Brian H. Powell)
Newsgroups: comp.sys.mac
Subject: Re: Control Panel Bug?
Summary: about relocatable cursors...
Message-ID: <9948@ut-sally.UUCP>
Date: 24 Dec 87 23:32:08 GMT
References: <9931@ut-sally.UUCP> <3646@husc6.harvard.edu>
Organization: U. Texas CS Dept., Austin, Texas
Lines: 30

> In article <9931@ut-sally.UUCP> brian@ut-sally.UUCP (Brian H. Powell) writes:
>>
>>     In a program I'm working on, I load all the cursors that I am going to
>>use at the beginning of the program, move them to high memory, lock them down,
>>dereference the handles and use pointers to them for the duration of the
>>program.  Fine.

In article <3646@husc6.harvard.edu>, singer@endor.harvard.edu (Rich Siegel) writes:
< 	It's not good practice to lock a handle, then keep its master pointer
< around, because exactly that sort of thing can happen. The best way to
< get the same effect is to preload the CURS resources and keep the CursHandles
< as global variables.

     That's sounds like a good idea, but I've got a question about it.  I
presume I should then have global handles to the cursors.  I shouldn't have
them locked.  So, my call would be
	SetCursor(*watch_cursor_hdl);   /* in C */

     But what if the cursor relocates while the watch is being displayed?  I
guess the question is, "Does SetCursor make a copy of the cursor and use that,
or does it use the actual cursor that it's given?"  If it's the latter, I'll
have to copy the cursor into a non-relocatable block of memory and use it
there.  What a waste.

     By the way, one of the recent tech notes about multifinder said that you
shouldn't modify the attributes of any of the system resources that are in
memory.  This means that my idea of locking the cursors is officially
verboten.

Brian