Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!pacific.mps.ohio-state.edu!linac!att!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: resource access from a cdev
Message-ID: <17239@hoptoad.uucp>
Date: 22 Apr 91 04:45:58 GMT
References: <159795@tiger.oxy.edu> <1991Apr17.170027.23710@bernina.ethz.ch>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Electronics for Imaging, San Bruno CA
Lines: 29

In article <159795@tiger.oxy.edu>, schorsch@oxy.edu (Brent William Schorsch)
writes:
>>Hello, everyone.  I've got one simple question: how can I get
>>access to several hundred resources from within a cdev?
>>Assuming that I have to start storing resources at -4033 (due to
>>the screwy "owned resource" stuff of DA's) having hundreds of
>>resources of the same type would have ID's which encroach upon the Control
>>Panel's reserved ID range--a no no.  If my assumption is wrong, please
>>enlighten me. 

In article <1991Apr17.170027.23710@bernina.ethz.ch> neeri@iis.ethz.ch writes:
>Your assumption is certainly wrong under current systems. The Control
>Panel assumes certain resources have fixed IDs, but it is not necessary
>for all cdev related resources to be owned by the cdev. I don't think
>this is likely to change in the future, as I can't think of one single
>cdev I have seen that complies strictly to the owned resource condition.

In order to prevent this problem, the Control Panel DA (at least under
6.0.x) plays fast and squiffy with the resource path.  It manages its
own separate list of resource files, so that whatever application it is
open under will not even see the open cdev resource file.  In other
words, although Inside Mac (V-338) says that resources for a 'cdev'
must fall in a certain range, there is very little risk in giving your
resources any IDs that don't belong to the system or to the Control
Panel DA.
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

A good flame strengthens its points; it does not stand in lieu of them.