ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) (10/18/90)
Something else occurred to me after I got home last night (funny, isn't it...) You could have two code resources with the same name, but of different types, in the same resource file. You'd need some way of distinguishing the resources owned by one from those owned by the other. In other words, you'd need to incorporate the type of the owning resource into the names of the owned resources. You could do this simply by prepending the four-character resource type onto the names of the owned resources. Thus, the resources owned by XCMD "Fred" would be called "XCMDFred:Properties" and "XCMDFred:Dialog". Further complication: the Resource Manager ignores case in resource names, but it does apparently distinguish diacritical marks (Inside Mac page I-110). This case-insensitivity may be a problem, since resource types are case-sensitive. If it is likely to be a problem, you'd need to add another byte to the name to get around this. By the way, those who think that the existing resource ID convention is all you need can ignore this discussion... Lawrence D'Oliveiro fone: +64-71-562-889 Computer Services Dept fax: +64-71-384-066 University of Waikato electric mail: ldo@waikato.ac.nz Hamilton, New Zealand 37^ 47' 26" S, 175^ 19' 7" E, GMT+12:00 To someone with a hammer and a screwdriver, every problem looks like a nail with threads.
newbery@rata.vuw.ac.nz (Michael Newbery) (10/18/90)
Why not follow the 'BNDL' approach ('bndl' perhaps, which would of course
require Apple's blessing)? The 'bndl' resource could simply be a list of
associated resources. Much more general and easier to localise.
--
Michael Newbery<newbery@rata.vuw.ac.nz>
Why do they always say "ROAD WORKS" when it doesn't?mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher) (10/18/90)
In article <1990Oct17.220257.26134@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: >Why not follow the 'BNDL' approach ('bndl' perhaps, which would of course >require Apple's blessing)? The 'bndl' resource could simply be a list of >associated resources. Much more general and easier to localise. This wouldn't work because you need to be able to have such a bundle for every resource ID of every possible resource type, not just of one type. You can't express that with one 16-bit resource ID, unless you do a lot of collision detection and renumbering. Matthias ----- Matthias Neeracher mneerach@iiic.ethz.ch "These days, though, you have to be pretty technical before you can even aspire to crudeness." -- William Gibson, _Johnny Mnemonic_
ech@cbnewsk.att.com (ned.horvath) (10/19/90)
In article <1990Oct17.220257.26134@comp.vuw.ac.nz> newbery@rata.vuw.ac.nz (Michael Newbery) writes: >Why not follow the 'BNDL' approach ('bndl' perhaps, which would of course >require Apple's blessing)? The 'bndl' resource could simply be a list of >associated resources. Much more general and easier to localise. From article <12084@neptune.inf.ethz.ch>, by mneerach@iiic.ethz.ch (Matthias Ulrich Neeracher): > This wouldn't work because you need to be able to have such a bundle for > every resource ID of every possible resource type, not just of one type. > You can't express that with one 16-bit resource ID, unless you do a lot > of collision detection and renumbering. The assumption would be that any given file would have a (fairly small) number of code objects contained in it, so the "neoBNDL" name space could be shared by all possible code resource types. A BNDL's first two fields are signature : OSType; versionID : INTEGER; If we assume that the neoBNDL replaces that with ownerType : OSType; ownerResID : INTEGER; then a simple hashing scheme (like summing the Type and ResID to get a trial hash key, and just incrementing on a collision) would suffice for any code resource that knew its own name to rapidly "guess" its neoBNDL resID. The initial key must be chosen a BIT more carefully to avoid conflicts with preassigned "owned" resIDs. Notice, however, that the entire application namespace (resIDs 128..32767) is open for neoBNDLs. A ResCopy facility could apply the same heuristic to quickly discover whether an arbitrary resource has "owned" resources, once the convention was sufficiently widespread. There, I've almost written the code. Perhaps I SHOULD write the code (unless there's a volunteer...) =Ned Horvath=
rad@genco.uucp (Bob Daniel) (10/20/90)
In article <2005.271d7a03@waikato.ac.nz> ldo@waikato.ac.nz (Lawrence D'Oliveiro, Waikato University) writes: > >You could do this simply by prepending the four-character resource >type onto the names of the owned resources. Thus, the resources >owned by XCMD "Fred" would be called "XCMDFred:Properties" and >"XCMDFred:Dialog". I've attempted to implement something similar to this. The problem is that you can't (or I couldn't figure out how to) load a resource by name using, ie, a wildcard. I'm writing a DA that allows externals to be written by other developers. I would like more than just resource type to determine the type of resource they have written (code resource, that is). If using the above example; "XCMDFred:Properties", I need the ability to test to see if the resource exists containing 'Fred'.. thus, Get1NamedResource("*Fred*",type). If null is returned, no resources exist with 'Fred' in it. Of course for multiple resources with 'Fred' in it, you need CountNamedResources and Get indexed resources with the ability to use wildcards. Is there another approach to this? Is there an alternative in Sys7? _________ moof moof
vd09+@andrew.cmu.edu (Vincent M. Del Vecchio) (10/20/90)
> Excerpts from netnews.comp.sys.mac.programmer: 18-Oct-90 Re: New > convention for owne.. Matthias Neeracher@iiic. (806) > In article <1990Oct17.220257.26134@comp.vuw.ac.nz> > newbery@rata.vuw.ac.nz (Michael Newbery) writes: > >Why not follow the 'BNDL' approach ('bndl' perhaps, which would of > >course require Apple's blessing)? The 'bndl' resource could simply be a > >list of associated resources. Much more general and easier to localise. > This wouldn't work because you need to be able to have such a bundle for every resource ID of every possible resource type, not just of one type. > You can't express that with one 16-bit resource ID, unless you do a lot > of collision detection and renumbering. You're right, of course, but the idea that I got was that we were sort of going to assume that there would be relatively few bndl resources lying around and number them arbitrarily, either indexing through them to check, or (I just thought of this) perhaps naming them to check. e.g. bndl indicating resources owned by XCMD #1039 might be named "XCMD1039" or perhaps "XCMD040F". Apple does, after all, provide underused facilities for doing resource lookup by name. +-------------------------------------------------------------------+ | Vincent Del Vecchio \ #include <stddisclaimer.h> | | Box 4834 \ #include <stdquote.h> | | 5125 Margaret Morrison St.\ BITNET: vd09+%andrew@cmuccvma.bitnet | | Pittsburgh, PA 15213 \ UUCP: harvard!andrew.cmu.edu!vd09 | | (412) 268-4441 \ Internet: vd09+@andrew.cmu.edu | +-------------------------------------------------------------------+