Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!snorkelwacker.mit.edu!bloom-beacon!vaxeline!bootsie!olson
From: olson@bootsie.uucp (Eric K. Olson)
Newsgroups: comp.sys.mac.programmer
Subject: Re: amateur programming questions
Message-ID: <1991Feb20.023659.21317@bootsie.uucp>
Date: 20 Feb 91 02:36:59 GMT
References: <frost.666550441@watop> <1991Feb14.165107.7828@umiami.ir.miami.edu> <1991Feb19.185229.183@smsc.sony.com>
Organization: Lexington Software Design, Lexington, MA
Lines: 40

In article <1991Feb19.185229.183@smsc.sony.com> dce@smsc.sony.com (David Elliott) writes:
>Why is it that people tend to use ID numbers instead of using names
>to identify resources?

Resource IDs occupy only two bytes.  Meaningful resource names are almost
always longer.  Resource IDs probably resolve faster, too, since fewer
compares are needed.  Also, if the names are in English, where do you
store them? (not hard-coded into your app, according to the HI Guidelines)
[admittedly, these names, which only a nosy user would see, don't
have to be localizable, but...].

4Plus (editor extensions for THINK C) will create a "rsrc.h" file consisting
of #defines for each resource that has a non-null name in your
projectname.rsrc file.  This way, you can use the #define names, but
you're really using the resource ID.  When you build your application,
you can remove the names from the resources in projectname.rsrc (to
save space and add security), and your code still runs (and contains no
hard-coded resource names).

>In working on a TCL application, I noticed that there were no builtin
>ways to, for example, tell CWindow to use a named resource.  Instead,
>I had to convert the name to the resource ID myself, and hand that
>to the creation routine.

This is probably a good way to go about it.  Note that you don't have
to actually load the resource to get it's ID:

	SetResLoad(FALSE);
	aHandle = GetNamedResource('Blah', "\pHello");
	SetResLoad(TRUE);
	GetResInfo(aHandle, &idPtr, &typePtr, nameString);

The ID and Name are in the resource Map in memory.


-- 
Eric K. Olson, Editor, Prepare()      NOTE:     olson@bootsie.uucp doesn't work
Lexington Software Design             Internet: olson@endor.harvard.edu
72A Lowell St., Lexington, MA  02173  Uucp:     harvard!endor!olson
(617) 863-9624                        Bitnet:   OLSON@HARVARD