🚀 go-pugleaf

In article <238@cf-cm.UUCP> ralph@computing-maths.cardiff.ac.uk (Ralph Martin) writes:
>
>Optional my foot. Many of the toolbox routines have arguments which are handles
>and if the programmer isnt careful in locking them down, he will soon learn
>that understanding the Mac's "memory (mis)management model" is NECESSARY!

In most of the cases where handles are created by the Toolbox, the
programmer can treat them as uniterpreted 32 bit numbers.  The Toolbox will
take care of locking them if that is necessary, and usually will provide
procedure calls to access their contents.  In some (unusal) cases, however,
you do have to access the contents of a Toolbox handle directly and will
have to dereference it twice.

My original comment was intended to refer to the application-specific parts
of a program.  There is no requierment that you use handles internally in
your program, and since the Mac Memory Manager provides a way to create
pointers to non-relocatable blocks you have the freedom to choose the memory
management model you want.


>used MacApp, and all I can say is that it is of limited use. Among my
>criticisms are that parts of it are inconsistent or not thought

I don't claim that MacApp is perfect, only that it solves many of the
problems of Macintosh programming, andthat it is being improved (based on
developer feedback).

>through enough (e.g.the way modeless dialogs work), there are

The dialog support is being totally rewritten.  Part of the problem in the
old UDialog was that we tried to use the ROM Dialog Manager where possible,
and there was a mismatch in the models used by MacApp and the Dialog
Manager.  In MacApp 2.0, the new dialog unit doesn't use the Dialog Manager
at all, and things are much cleaner and more consistent.

>omissions (e.g. it is not trivial to put a picture you have a handle
>to on the clipboard - a very common requirement), if you try to do

I think this requires defining a new view class, but that's all.  It is true
that there are some classes that would be helpful to provide.  We tried to
make MacApp as solid as possible, and didn't have time to write very many
building blocks.  There are some building blocks available from the MacApp
Developer's Association.

>anything serious with it, you soon find that many things you want
>to do require overriding MacApp at much lower levels than should be
>strictly necessary, and the programmer STILL has to worry about memory
>management, despite the comment above - just look at the MacApp example
>sources if you want any proof! 

I think MacApp's memory management is as easy at will get on the Macintosh.
There is no virtual memory, so you have to worry about memory requests that
can fail.  You have to tell MacApp how much memory to reserve for your
maximum working set, and you have to check for errors returned by the Memory
If you do these 2 things then MacApp will make sure that your program
doesn't crash.

We have gotten some very positive feedback from MacApp users.  The fact is
that people have written some sophisticated programs with MacApp.  They
cover a wide range of application areas (music, word processing, filing,
engineering).  On the other hand, we don't usually hear from developers who
are unsuccessful with MacApp.

>A much larger library of classes will be needed (For example, the

MacApp 2.0 contains a larger variety of view classes.  There is also a way
to create all your views based on the description in a resource.  This
makes it much easier to create windows (including dialogs) in MacApp 2.0.

>The classes also need to be much better defined and documented (these
>are not the same). This will reduce many of the unfortunate side effects
>and interactions which make MacApp so tedious at present.

The manual is being rewritten and will include a tutorial section.  MacApp
2.0 has a lot of improvements to make it easier to use.  The first version
of any large system is always going to have deficiencies.

-- 
		 Larry Rosenstein,  Object Specialist
 Apple Computer, Inc.  20525 Mariani Ave, MS 27-AJ  Cupertino, CA 95014
	    AppleLink:Rosenstein1    domain:lsr@Apple.COM
		UUCP:{sun,voder,nsc,decwrl}!apple!lsr