[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
resources
- To: info-mcl
- Subject: resources
- From: doner@aero.org (John Doner)
- Date: 25 Nov 91 17:49:37 GMT
- Newsgroups: comp.lang.lisp.mcl
- Organization: The Aerospace Corporation, El Segundo, CA
- Sender: news@aero.org
Last week, I posted a note asking about the lack of support for the
Resource Manager in MACL. Immediately, several people directed me to
some contributed code by Matthew Cornell, which provides the Resource
Manager calls, and is available from cambridge.apple.com. To all who
replied, Thanks, this will be very helpful.
I did have in mind a more general question, however; I wasn't just
asking for an implementation. The fact is, the Resource Manager
underlies most things in the Macintosh Toolbox. So when a compiler
vendor sets out to provide a product for the Mac, one of the first
things is to set up support for the Resource Manager. If you look at
the standard Macintosh examples of how to write applications, you'll
find that implicit Resource Manager calls are used everywhere. For
example, the standard way to put up a dialog is to use GetNewDialog,
which expects a resource id and reads in the data from a file. This
way, the parameters of the dialog, including the text of messages and
placement of items are not hard-coded into the program, but rather
easily changed not only by the programmer, but also by the language
translator, even the knowledgeable end user.
Thus my puzzlement upon finding no support for the Resource Manager
within MACL. Seen from the perspective of other languages, this
support is so important that it cannot be left to user-contributed
add-ons. So I'm really asking, what were the design considerations
that led to its omission from MACL?
Don't get me wrong, I like MACL, and I think its designers did a
brilliant job. But there is this one thing ...
To describe more precisely the sort of support I'm talking about,
let's take GetNewDialog as an example. With Matthew Cornell's code,
one can read in the necessary DLOG and DITL resources. It remains to
create the Lisp object, using the information read in along with the
functions kindof, exist, and so on (I'm not yet knowledgeable enough
with lisp or MACL to say exactly how, sorry). In other words, one
must somehow tell lisp that the stuff read in is a dialog and
generally make it capable of interaction with the various functions
for dealing with dialogs.
John Doner doner@aero.org or doner@henri.ucsb.edu