March 94 - Editor's Notes
Editor's Notes
Mary Elaine Califf
Welcome to the March/April issue of FrameWorks. As usual, we have a wide variety:
articles focusing on MacApp, Prograph, TCL, general C++ coding, and general
object-oriented programming and design issues. This issue includes a lot of practical
programming advice with source code.
Several of our regular authors are back with interesting pieces. Kurt Schmucker's
Prograph column continues with an implementation of DemoDialogs, complete with
source code on disk. His discussion will be of interest to all who are using Prograph or
considering it as a potential development environment. Bob Hablutzel also continues
his column in this issue, though it has changed from the question and answer format to
a general column on useful programming techniques. In this issue he addresses the
issue of using command-modifier-key combinations with menus when using MacApp.
He provides source for handling them on disk. Andy Dent is also back with another
TCL-related article. This time he describes the latest version of Marksman and
presents his templates for generating TCL-compatible code with Marksman. Those
templates and a tutorial are on the FrameWorks source disk. On a more theoretical
note, Mikel Evins is back this issue with a discussion of protocols and their
importance.
And more
Our Tricks of the Trade feature is back this issue with a tip from Lillian Beean. She
describes how to set things up for source level debugging of code resources with The
Debugger. An example is included on the source code disk. In another useful article,
Adam Wildavsky provides an approach to finding memory leaks. His TApplication
subclass, TTidyApplication, is provided on the code disk in both MacApp 3.0.1 and 3.1
versions. (Is this beginning to sound like an advertisement for our disk
subscription?)
Ron Reuter provides the solution for a common problem: providing "marching ants
feedback for mouse tracking. His code is, of course, also on the disk. Finally, Serge
Froment probides a set of framework independent C++ classes for managing dates and
times. His UDateTime code is also on the disk.
Contributing Editors
You may have noticed that we have a number of new authors, several of whom have
written multiple articles. I want to take this opportunity to mention the most recent
additions to our contributing editors: Kurt Schmucker and Mikel Evins. Contributing
editors write at least four articles a year for FrameWorks.
My soapbox: The value of IconEdit
I don't often use this space to express opinions, but lately I've formed a rather strong
one. I occasionally hear complaints or at least derogatory comments about IconEdit, the
MacApp tutorial. I've made some of those comments myself, and I think that the
IconEdit tutorial could probably be improved. However, over the last couple of years
I've been learning to use several new development environments, among them
Macintosh Common Lisp, AAIS Full Control Prolog, and QKS SmalltalkAgents, all
interesting environments with a lot of good qualities, and all more appropriate to my
current needs than MacApp. However, trying to learn to use these systems has taught
me the value of IconEdit, because none of them provide the kind of tutorial that IconEdit
provides: something that takes a new user through the process of developing a
complete, if very simple, application step-by-step, simultaneously demonstrating a
few useful techniques on the way.
I'm afraid that tutorials like IconEdit are sometimes undervalued. Certainly they are
not the be-all and end-all of documentation. IconEdit alone won't get you far. Some
creators of development environments seem to think that the provision of ample
example source code can replace tutorials, while others seem to assume that you can
take courses to learn how to use their environments. Certainly, sample source is
invaluable, and courses can be useful. However, I represent what I think is a not
uncommon situation. When I first learned MacApp, I was the first person in my
department to start using it. I had convinced my superiors that the Hypercard stacks I
had inherited needed to become applications (not a difficult task since they were
crashing people's systems), and I knew that MacApp was "the right thing to do." But I
was the first, and no one was going to spend money to send me to a class anywhere.
IconEdit didn't teach MacApp, but it did give me a boost.
With the other environments I mentioned, I have had equivalent resources for
learning: nothing but what's provided with the system. These systems do provide ample
source, fair to good documentation, and, in two cases, short introductory tutorials.
However, they lack tutorials that take the developer step by step through the creation
of an application on the order of IconEdit, and this, I think, has made it a bit more
difficult really USE the environment initially.
So I have a plea to all developers of development environments: Provide IconEdit for
your environment. Not necessarily that application, of course. But provide a tutorial
that guides the developer through the creation of an application, preferably not a
completely trivial application.
Off of soapbox.
Stay tuned
In coming issues, we'll have reviews of SmalltalkAgents, CodeWarrior, and QD3D,
articles on Marlais (a partial implementation of Dylan), a report on the conference,
our regular features, and more!