WAMADA News)
John MacVeighC
August – MacApp, TCL, & FUDZ
RThe August WAMADA meeting began with a little group troubleshooting for some localf
Qdevelopers. They brought up some shortcomings in MacApp which they wanted to workr
Saround. The first involved printing to a LaserWriter vs. displaying with QuickDraw.~
UTheir application creates and prints forms for a government agency (big, long forms).
QNaturally they wish to make use of the printing quality available on a PostScript
Tprinter. For example, the printed forms should use lines thinner than a standard one
Tpixel QuickDraw line. But how to do this with MacApp's printing mechanism? The first
Msuggestion was to pre-build the forms in PostScript and "fill-in-the-blanks".
VHowever, this application constructs the forms as it is run, thus there is no standard
Nform to pre-build. Apart from writing everything in PostScript, the only other
Wsuggestion was to first produce a PICT so that the PostScript could be embedded in PICTfi
Rcomments. The idea was to alter the printing loop to open a picture, call the DrawÍ
Qmethods which could add PICT comments where needed, then close the PICT and printˆ
Othat. This seemed doable, if not pretty. Since desktop publishing was the Mac's
Tsalvation in the early years, and is still a strength today, one might expect better
Qprinting support from MacApp. But what we have been given is only QuickDraw, i.e.
Sthe lowest common denominator (where have I heard that phrase before?). To say that
RGX will solve this problem is correct, but smacks of raising the river rather than
lowering the bridge.
TThe second problem involved MacApp's sometimes haphazard use of color, especially in
Wdialogs. For example, the floating TE view must be overridden to make use of the target
Kview's foreground and background colors. Other color problems are caused by
SMacApp's use of standard Mac controls. Perhaps Bedrock will help solve this problem
:by abstracting controls into platform independent objects.
TCL
KThe evening continued with a presentation by Mark Gerl of McDonnell Douglas
Qcomparing TCL with MacApp. Mark's group recently switched from MacApp 3.0 to TCL.
TThey did so partly based on the loss of support for MacApp, and partly on the belief
Sthat Bedrock will be more like TCL. In the end, they may have tried to hit a moving
Ttarget; but given his group's existing knowledge of MacApp and their emphasis on R&D
Wprototypes rather than finished product, I don't think they have lost anything. Indeed,
NTCL may be a better starting point for prototypes and experiments. Some of the
benefits of TCL include:2• Shorter learning curve'2• "Lighter" classes=2,• Fast environment with integrated debuggerS28• AppMaker™ support for quick start up of new projectsi2H• Works with Object Master and Projector(Mark edits with Object Master,u2Kuses MPW to run Projector (SourceServer's still in the wings), and does the 2Ecompile/link/debug work with Think C. This gives him the best of each 2Kapplication. It also gives him a reason for using a 32MB Radius Rocket™ to 2run Think C.)
VIt's not unexpected for a smaller framework to be faster to learn and work with than a
Plarger one. But does it warrant giving up the richer and more complete (System 7
Psupport, for example) fra