Path: utzoo!attcan!uunet!mcsun!ukc!mucs!liv-cs!liv!kpurcell
From: KPURCELL@LIVERPOOL.AC.UK
Newsgroups: comp.sys.mac.misc
Subject: Re: NeXT Mach (was Re: UNIX is yuck (was Re: Next intro...)
Message-ID: <90309.231331KPURCELL@LIVERPOOL.AC.UK>
Date: 5 Nov 90 23:13:31 GMT
References: <1990Oct6.172357.18366@smsc.sony.com> <1990Oct8.091751.3053@csc.anu.oz.au> 
  <4b5vB5e00UhBA=gi8V@andrew.cmu.edu> <1990Oct15.224912.26056@eng.umd.edu> 
  <21288@well.sf.ca.us> <1990Oct22.213553.20022@Neon.Stanford.EDU> <90301.081741KPURCELL@LI <1990Oct29.
Organization: University of Liverpool
Lines: 102

In article <1990Oct29.231127.3763@CAM.ORG>, pascal@CAM.ORG (Pascal Gosselin)
says:

>I am presently writing ultra-simple front ends to 'standard' Pascal and
>C applications with the help of PROTOTYPER.
>
>Prototyper lets you design the Mac user interface, and it generates the
>code for you (the skeleton (event loop), one 'Unit' per window/dialog,
>etc... and all the resources too).

The other choice is AppMaker -- and from what I hear it may be a better choice.
I received this mail when I was looking into getting one or the other a
short time ago:

Does anybody know if any of the big mail-order houses is discount AppMaker?

I think it generating code for THIBK Class libaries is a big win (but not
much use if your using Pascal -- I think Prototyper supports Pascal).

Comments from a review in MacUser: The code generated by AppMaker looked
better and was about 3 times smaller than that for Prototyper.


Kevin Purcell          | kpurcell@liverpool.ac.uk
Surface Science,       |
Liverpool University   | Programming the Macintosh is easy if you understand
Liverpool L69 3BX      | how the Mac works and hard if you don't. -- Dan Allen

------------------------------------------------

Date: Fri, 13 Jul 90 13:12:46 -0500
From: Jonathan Mills <jwmills@edu.indiana.cs.iuvax>
To: KPURCELL@uk.ac.liverpool, tcm@edu.rochester.cs.cayuga
Subject: AppMaker
Cc: jwmills@edu.indiana.cs.iuvax


I have been using AppMaker for the past four months.  It is a good _tool_
but it is by no means magic, particularly in the design of the user interface.
In fact, AppMaker alone is insufficient to design the interface, and should
be used with ResEdit.  This is not to say that AppMaker is bad, simply that
the last 5% of your design will probably require some twitches with ResEdit.

Examples:

    1.  Designing a pop-up menu in 9 point Geneva font.  You must use
            ResEdit to change the AppMaker templates so that windows use
            a font other than Monaco 12; or you must remember to add code
        to your C source.  You must also resize the pop-up box using
        the Get Info.. AppMaker dialog;  if you move it around be
        prepared to resize it again, as AppMaker will reset the box
        to its defaults.

    2.  Use the window font in a button.  You must change the ProcID
        of the button by adding 8, in ResEdit.

    3.  Remove unused picture resources.  You must delete them with
        ResEdit.  Once a picture is in the AppMaker .rsrc file, it is
        not deletable with AppMAker.

Also a warning:  Very occasionally, but regularly, if you cut a resource such
as a picture button out of a window or dialog, the AppMaker .rsrc file will be
damaged beyond repair.  Somehow the file is blanked, perhaps because the EOF
mark is set to the point just after the previous resource, but the file cannot
be recovered even by twiddling with MacTools, etc.  So, I always make a copy of
the AppMaker file before I begin to edit it.

Some good points:  AppMaker code is concise and readable.  This is because the
C generation is done with templates specific to a language system or sub-system.
Think C, MPW C, and Think C with Class Library _all_ have different templates.
In fact, you can't switch from one to the other without re-generating code;
compiling alone may cause the application to bomb.

I use Think C, and have found that AppMaker's automatic generation of "stubs"
was tailor-made for structured programming.  Wherever you must write user-
defined code, there AppMaker puts a stub.  It is trivial to collect these
stubs into your own code's modules.  It is also necessary:  if you modify the
interface, and regenerate code with AppMaker, you will _lose_ all of the code
you added to the module.  (Sonce you may want to modify a module sometimes,
it is best to collect these modules and put them in a sub-folder during code
generation.)

In closing, although this message may sound negative, it really isn't, and I
**strongly** recommend AppMaker.  It does most of a typical Mac interface
automatically; it allows custom design of picture buttons, palettes &
sliders; it does picture menus;  it has source for its CDEFs;  it can be
customized to generate code;  the technical support is *incredibly* good
and the staff at Bowers Development very responsive;  and they are working to
improve the product:  tear-off windoids, "sticky" controls in resizable
windows, picture pop-up menus and more are all in the works based on their
user's suggestions.

I don't work for them, but spent a week or so bugging the staff daily until
I had the hang of AppMaker.  (This was in part because my interface is
simple but thus not what the applicaion was intended to support.  However I
have been able to do most of it with AppMaker after a little thought.  If
you want to see my interface, which is an example of most of AppMaker's
features, perhaps I can find a way to send you the Stuff'ed & BinHexed
application.)

Sincerely,
Jonathan