ADVERTISEMENT

Strip Printing

By Kirk Chase, Editor

Larry Resestein at August BAMADA

James Plamondon

Fourth Wednesday of the month at 7PM, in the Mountain View Room of Apple’s City Center Four building, at 20450 Steven’s Creek Boulevard, Cupertino

Larry Rosenstein, MacApp wizard, was the speaker at the August BAMADA meeting where he discussed a few ideas from his book, C++ Programming with MacApp. First, he discussed filtered commands, which are described in detail in Chapter 25 of his book. The goal of the filtered command mechanism is to reduce the amount of information that one must maintain in order to undo or redo a command.

Larry gave the example of a styled text document, containing hundreds of different style runs (a little bold Times, some 9-point Zapf Chancery, a dash of italic Courier, etc. -- a real ransom-note document). If the user selected all of the document’s styled text, and set it to plain Geneva 12, saving the previous state of the document -- with all of its different styles -- could take a lot of space; in the worst case, you might have to save off the entire document.

Filtered commands solve this problem. Instead of saving the pre-change data, and then altering the document in accordance with the command, the command just installs a filter into each affected piece of data which makes it LOOK as if it has been changed. In the example above, each style run object would be filtered to look like it was plain Geneva 12. To undo the command, the filter is simply removed; to redo it, the filter is reapplied.

The mechanics of the approach are beyond the scope of this summary; besides, you can find them in Larry’s excellent book. Suffice it to say that the use of such commands simplifies the implementation of Undo/Redo significantly, and reduces the storage costs associated with it, at the cost of slightly slower data access times.

After Larry shined his light on filtered commands, he moved on to streaming. Streaming is also discussed in his book (in Chapter 22), and is a major feature of MacApp 3.0. By using streams for data I/O, one can handle input and output more abstractly; one can stream to a file or to the clipboard with equal ease.

The basic idea is that the TStream class is responsible for reading and writing bytes, or aggregates of bytes, from and to “something.” TStream’s subclasses implement the abstract methods that do the reading an writing. For example, a TFileStream would implement reading and writing to a file, while a THandleStream would implement reading and writing to a memory block. A TCountingStream wouldn’t read or write anything -- it would just count the bytes that it was told to write; this is particularly useful when trying to find out if there’s enough room on a disk to hold a file, before you actually write it out (via a TFileStream).

Larry’s book describes streaming in much more detail than this, of course, and you’ll want to look into it, as streams are used extensively in MacApp 3.0.

Article missing

MacTutor

Due to an oversight on our part, the last part of Brendan Murphy's article on Modeless SFDialogs was missing. Here is a reprint of that final section.

Conclusion

After reading this article there are probably a lot of unanswered questions. These questions are left to the reader as an exercise (I always hated that in college). I’m not going to produce a Think C version or a MacApp version. I leave this honor to some hearty soul out there. I will release a maintenance version if enough bugs or deficiencies are brought to my attention. My hope for this piece of software is that it will someday be incorporated into Apple’s system software (7.x or 8.x) and thus make this article a moot exercise for future programmers.

In the future, I plan to write more articles on TCL and perhaps MacApp. I am already “cooking up” some ideas to remove some of the short comings of TCL, but I have not yet decided which idea to pursue. Half the battle is coming up with the idea and half the battle is sticking with the idea and half the battle is implementing the idea. Yes, that adds up to 3/2 which goes to show that anything worth doing, is more work than you thought.

A Problem Stripping

Deborah E. Meadow

Now that the title has caught your attention, here is somthing interesting. While a the Boston MacWorld, Deborah Meadow approached me with an unsual problem. From the above address, you can see that she works for a medical group. Her problem involves printing. Some things such as EKG strips are printed in a continuous fashion, i.e. they are not spooled by the page as Mac printing is usually done. What she would like is help in creating, hopefully, a general purpose driver to do real-time, strip printing. If you have an idea, please get in touch with her at the above address.

Cheshire Keeps on Smiling

Cheshire Grin Productions Ltd.

Cheshire Grin has just added two new additions to their Stack Enhancers product. The first addition is the Browser Palette. This allows the user/developer to navigate cards quickly and do card management, such as renaming cards; its immediate benefit is navigation for incomplete stacks. The second addition to Stack Enhancers is the Search Palette. This palette allows you to search for text on a particular stack-great for keeping a list of cards that meet the search criterea. Contact Cheshire Grin for more information.

Prospective International Software Developers

The Software Toolworks

Planning on making a trip overseas to a trade show or just curious about the world around you? The Software Toolworks has the product for you, World Atlas. This product puts the atlas on your computer. It comes complete with over 250 detailed maps in either black & white or color. There is also a database covering information such as population, climate, national holidays, and travel documents. Sort of a one stop shop in world travel information.

BitMap Error

Kirk Chase

I would like to point out an error in some code published in MacTutor, November 1990 ("Special Effects") and June 1991 ("Kolorize Your B&W Application"). Basically the code in question is the offscreen bitmap allocation function used in both articles. The offending line in the procedure NewBitMap is

bm->baseAddr=NewPtr(bm->rowBytes *(long (r->right - r->left));

This assumes a height the same size as the width. Correct it to the following:

bm->baseAddr=NewPtr(bm->rowBytes *(long (r->bottom - r->top));

Thanks to Randy Frank for pointing this out.