[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: resources
- To: DONER@AERO.ORG
- Subject: Re: resources
- From: UK0392@AppleLink.Apple.COM (EHN & DIJ Oakley,BDV)
- Date: 26 Nov 91 18:48 GMT
- Cc: INFO-MCL@CAMBRIDGE.APPLE.COM
John,
You write:
----------------------------------------------------------------------------
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?
----------------------------------------------------------------------------
I am afraid that I must disagree with you completely. I should point out that
I too am an MCL novice (although now on my second MCL app), but have been
programming commercially on the Mac for a fews years, initially rolling my own
apps, then (and still) using MacApp.
You *can* do everything that you ask in MCL, using the low-level ToolBox calls
which are accessible from MCL. You can also design and build your own computer
from scratch, but I think that this is a rather slow way to get round to
writing a program. You see, the ToolBox dialog architecture may be very
convenient to use with ResEdit, but it does not (yet) fit any OOP system too
well - for example, MacApp has also abandoned conventional dialogs and gone for
its own form of views (well, really at least 2 forms of views, as they are
a-changin'!).
MCL's equivalent is in its own view architecture, which admittedly runs
entirely on procedural view creation (whereas MacApp allows both procedural and
resource-based methods), but is *really neat*. Very powerful, relatively fast
(MacApp views are beginning to get decidely turgid, as they get more
complicated), flexible, and the editor is just the job. Sure, you cannot edit
them in ResEdit, but neither can you edit MacApp or any other OOP-based view
system with ResEdit, as dialog resources are too primitive to fit in well with
the modern complexities of OOP systems. Maybe with Pink, dialogs will get
dragged screaming and kicking into the 90s, and OOP languages can use the same
as everyone else, but until then, just be grateful.
Oh - and if you decide to have a go at accessing old-fashioned resource-based
dialogs from MCL, and get fed up with the amount of work involved, and all that
low-down programming, then remember that you are only doing what everyone else
using non-OOP systems has also got to do before they can use them - MCL is not
specially disadvantaged in that respect, it just looks that way because the MCL
view approach is so good.
Howard.