jg@eagle.ukc.ac.uk (J.Grant) (06/02/88)
I have always wanted to change the normal pointer icon, you know the
'`
\
\
into a left-handed person's pointer, since this one is obviously
for a right-handed person (think about where you put the mouse).
I presume (albeit probably incorrectly) that this lurks in the ROM.
Is there anyway to change it, like putting a resource with a suitable
number in the system file, for instance ...
How ??? Or more correctly what & where ?
{I have hesitated at guessing that a curs of id 0 in the system file,
might work (it wouldn't be the first hard-disk that I have had to
re-format after trying something like this - p.s. I tried all the tricks
to recover the disk, but no dice at all - most utilities would
not even admit that there was a hard disk!).}msurlich@faui44.informatik.uni-erlangen.de (Matthias Urlichs ) (06/06/88)
In article <5157@eagle.ukc.ac.uk> jg@ukc.ac.uk (J.Grant) writes: > I have always wanted to change the normal pointer icon, you know the > > '` > \ > \ > > into a left-handed person's pointer, since this one is obviously > for a right-handed person (think about where you put the mouse). > > I presume (albeit probably incorrectly) that this lurks in the ROM. > Is there anyway to change it, like putting a resource with a suitable > number in the system file, for instance ... > > How ??? Or more correctly what & where ? I have written a small INIT, called "Color Cursor", which does exactly this. It probably could be changed to use "normal" cursors easily. The normal arrow cursor is, unfortunately, not in any resource (not even in ROM). So what you do is to patch SetCursor to look at the cursor image, compare it with the image of the standard Arrow you've stolen from the QD Globals (by now, I stored it in a resource inside my INIT), and if equal, call SetCursor (or SetCCursor) with your own cursor instead. I could mail the source (or post it to comp.sys.mac.programmer) if anyone's interested (it's quite small). -- Matthias Urlichs CompuServe: 72437,1357 Delphi: URLICHS Rainwiesenweg 9 Phone: +49+911-574180 8501 Schwaig 2 NetMail: m_urlichs@msn.rmi.de West Germany or: (r)eply and (h)ope
David_Alan_Newman@cup.portal.com (06/09/88)
As an aside to this discussion, I thought I'd through out a discovery we made earlier this week. For months now, people have reported sightings of a 'trashed' cursor in our product. We only figured out what was causing it two days ago. We relied on the system provided cursors. Normal arrow, edit Ibeam, watch, and fat plus. We found that some DA's, and/or other applications running under MF would issue ReleaseResource calls for all the cursors they had used. This would in effect 'yank' the system cursors right out from under us! System resources are supposed to be shared, image if people started issuing releases for WDEF's, CDEF's, etc! We've taken to using our own cursor resources now, insted on relying on the system provided cursors, with the exception of the normal arrow, which in theory can't be dispossed of. If anyone else has experienced this problem, prehaps this is the cause. And for those of you talking about writting cursor INIT's, remember that there are other applications out there that expect resources to be there, but don't neccessarily care what color they are. Dave Newman Software Ventures
kaufman@polya.Stanford.EDU (Marc T. Kaufman) (06/10/88)
In article <6383@cup.portal.com> David_Alan_Newman@cup.portal.com writes: >As an aside to this discussion, I thought I'd through out a discovery we >made earlier this week. >We found that some DA's, and/or other applications running under MF would >issue ReleaseResource calls for all the cursors they had used. This would >in effect 'yank' the system cursors right out from under us! System resources >are supposed to be shared, image if people started issuing releases for >WDEF's, CDEF's, etc! For the paranoid (and I count myself among them) you can DetachResource to make a private copy of the cursor for yourself. This avoids having to have copies in your resource file. In general, I am not sure what one is supposed to do about shared system resources. I don't want them cluttering the heap if I no longer need them, but I don't want to offend DAs. Perhaps one should GetResource before EVERY use of the resource, but mark it purgeable... but then you have to decide what to do if there is not enough room in the heap to reload it. At least Cursors are small. Marc Kaufman (kaufman@polya.stanford.edu)
anson@spray.CalComp.COM (Ed Anson) (06/15/88)
In article <6383@cup.portal.com> David_Alan_Newman@cup.portal.com writes: > >We found that some DA's, and/or other applications running under MF would >issue ReleaseResource calls for all the cursors they had used. This would >in effect 'yank' the system cursors right out from under us! System resources >are supposed to be shared, image if people started issuing releases for >WDEF's, CDEF's, etc! This is only a small part of a larger problem I've noticed. Sometimes, there are several parts of the same application that must get and release various resources. Sometimes they are the same resources. The current situation forces me to one of several alternatives: 1) always leave the resource allocated after getting it (wasteful of memory); 2) do a DetachResource to keep other modules from releasing it (even more wasteful, in general); or 3) set up a complex bookkeeping system so that I know which resources are still needed. A PROPOSAL: Why doesn't Apple just modify the resource manager so that it keeps track of how many requests for a resource are still outstanding. This would mean adding a "use count" to the master pointer block. Applications would then be required to balance gets and releases of each resource. Of course, a compatibility mode could be provided which would cause the old behavior to occur by default -- but only within one application. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM
dwb@Apple.COM (David W. Berry) (06/16/88)
In article <2340@spray.CalComp.COM> anson@spray.UUCP (Ed Anson) writes: :In article <6383@cup.portal.com> David_Alan_Newman@cup.portal.com writes: :> :>We found that some DA's, and/or other applications running under MF would :>issue ReleaseResource calls for all the cursors they had used. This would :>in effect 'yank' the system cursors right out from under us! System resources :>are supposed to be shared, image if people started issuing releases for :>WDEF's, CDEF's, etc! : :This is only a small part of a larger problem I've noticed. Sometimes, there :are several parts of the same application that must get and release various :resources. Sometimes they are the same resources. : :The current situation forces me to one of several alternatives: 1) always :leave the resource allocated after getting it (wasteful of memory); 2) do :a DetachResource to keep other modules from releasing it (even more :wasteful, in general); or 3) set up a complex bookkeeping system so that :I know which resources are still needed. 4) Use the series: LoadResource(rsrc); use resource ReleaseResource(rsrc); instead of just assuming rsrc is already in memory. This works in both cases (ie., you releasing a resource from a far, and somebody else releasing your resource) And takes very little time. For resources that you don't keep pointers to, ammend it by doing GetResource, LoadResource. Note that this is actually a good habit to get into anyway (especially in "visitor" code, since the "host" may have SetResLoad(false)).
anson@spray.CalComp.COM (Ed Anson) (06/20/88)
In article <12237@apple.Apple.COM> dwb@apple.apple.com.UUCP (David W. Berry) writes: > 4) Use the series: > LoadResource(rsrc); > use resource > ReleaseResource(rsrc); Looks good. Except for one thing: As I read Inside Mac, the ReleaseResource invalidates the handle. I interpret this as meaning that the master pointer is invalidated as well. So, this sequence would work for two unrelated programs (or program parts) only if each GetResource returns a handle with a separate master pointer. I don't think that happens (at least it shouldn't!). I admit I've never tried this. I'm reluctant to try anything that doesn't look iron clad and guaranteed. This doesn't. -- ===================================================================== Ed Anson, Calcomp Display Products Division, Hudson NH 03051 (603) 885-8712, anson@elrond.CalComp.COM