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!