Happy Aniversary

By David E. Smith, Editor & Publisher, MacTutor

Prototyper™ vs FaceIt™ vs Programmer’s Extender™

George R. Cossey

First let me say that the goal of Prototyper™ is similar to the other two products, but the implementation is very different. The goal for all of us is to make designing and building a Macintosh program less painful.

Prototyper™ has a built-in visual editors and simulators for interactive graphical design of the user interface, while the other two products provide no direct visual interaction in the program design.

Prototyper™ generates source code that uses only Mac Toolbox and does not supply any private or additional libraries for linking to. The other two products supply libraries to link to and provide their own toolboxes to interface to. The other two products supply libraries to link to and provide their own toolboxes to interface to the Mac interface.

Programmer’s Extender™ and FaceIt™ both try to make the Mac interface less of a challenge by using custom designed libraries that combine the functionality of multiple toolbox calls along with some canned control code. My objection to that method, as a programmer, is that canned libraries work for only specific conditions and if my program requires something a little extra that is not in the canned library then I have to replace it with my own code that uses the Mac Toolbox anyway. Prototyper™ generates source code that uses only the Mac Toolbox, so any “tweaking” that I have to do to a routine is easily added.

I commend both Programmer’s Extender™ and FaceIt™ for developing their own interface libraries to make programming on the Mac easier. Programmer’s Extender™ is a fine product that shows the dedication and high level of expertise of the designers. FaceIt™ is a fairly recent newcomer and has potential to provide the same level of functionality that Programmer’s Extender™ does.

In summary, I developed Prototyper with two main goals in mind. The first was to make designing a program’s interface like painting a picture in MacDraw, with objects that could be resized and repositioned visually. The second was to provide source code that used only the standard Mac Toolbox and not any special libraries. Both objectives were realized with Prototyper™, and I feel it is in a different class than Programmer’s Extender™ and FaceIt™ which use special libraries of functions.

[I commend Mr. Cossey on his excellent product. I like designing my interface at a MacDraw-type level. I would say that this type of development tool is for programming like the Mac was for user interfaces. This is not to say that I do not like or use the other products when doing my own developing.

Word 3.01 Word Wrap

Steve Seaquist

After much more sleuthing, I’ve determined that font widths on the screen do not vary according to what printer is Chooser’d. The reason why word wrap and tab stops vary between ImageWriters and LaserWriters is Word’s variation of how it measures an inch:

• Chooser an ImageWriter, then Show Ruler, then get out a real-world ruler (a tape measure, for example) and hold it up to the screen. The inches that Word shows are notably longer than real-world inches.

• Now start a print job using Tall Adjusted. Afterwards, the word wrap point will change. Then do a Page Preview. Afterwards the on-screen ruler’s measurements will also change, and the new ruler’s inches will be a lot closer to (a tiny bit shorter than) real-world inches. (The requirement of doing Page Preview to change the ruler is probably a bug. It should change automatically to reflect current word wrap and tab stops.)

• I believe Word is using THPrint()^^.prInfo.iHRes to determine the number of pixels per inch in the on-screen ruler will accurately reflect the number of inches when the document is printed. This is the old aspect ratio problem.

• Dots on the screen are square 74dpi x 74dpi.

• Dots on IW, Tall are rectangles 72dpi x 80dpi.

• Dots on IW, tall adj. are square 72dpi x 72dpi.

To answer my previous questions:

(1) There is indeed a good reason to change word wrap and tab stops when changing between IWs and LWs. The difference in aspect ratio would yield a different number of characters that could fit comfortably on a line. Because only the center or end point(s) positions of lines are guaranteed, the LW driver’s QD-to-PS bottlenecks would generate lines longer than anticipated (left, right, or centered justified) or too compressed (fully justified). So the passage at the beginning of Tech Note 72 (about printing to LWs the same way as you would to IWs) is misleading.

(2) Contrary to my earlier suspicions, Word wasn’t playing any tricks to change screen font widths. In actuality, printer resolution changes printout font widths, and Word simply adjusts its screen display accordingly.

(3) The trick to getting IW rough drafts of Word documents that are intended to be LW’d is to use Tall Adjusted. I haven’t seen any mismatches yet, and I don’t anticipate seeing any, because Word seems to use the same 72 dpi ruler in either case. Too bad Microsoft’s hotline people didn’t know this. It would’ve save some people a lot of sleuthing.

I’m tempted to use Tall Adjusted and LW fonts in all Word documents, so that the decision of whether to LW the doc can be postponed. Unfortunately, Tall Adjusted seems to slightly improve, but not eliminate, the problem where Best mode printing jams together words that are in LW fonts. This makes Best mode Worst and eliminates the qualitative middle ground between Faster and LW (a middle ground that still exists if the doc is in an IW font). My only guess as to what causes that problem is the facts that FScaleDisable implies FractEnable (Tech Note 92, page 2) and Best mode printing is scaled down from the double-size font if available.

[You would think that a big software corporation such as Microsoft wouldn’t have such problems. I love Excel, and I tolerate Word. David uses WriteNow; there are a lot of advantages to this product. It can handle lots of pages without slowing down; it can control leading, but for some of the editing work which I do, WriteNow’s quirks just make me shake my head and say it is not much better than MacWrite. I was hoping FullWrite may answer my dreams, but I don’t have the megs or the speed to give me what I need. I’m looking into WordPerfect now for my editing needs. I know it won’t be perfect either, but it has some promise. -ed]

More DB and C

Michael D. Sammer

Please let me compliment you on the fine journal, MacTutor. I enjoy reading it thoroughly, and it is very helpful. I program strictly in C, therefore, I would appreciate it if we could see more articles on C. This would be extremely helpful to me. Specifically, some articles on database management, hashing tables, and details regarding definitions of records in a file would be very helpful. Techniques for manipulating data back and forth from the disk to a data structure, efficient ways to mark the end of a record in a database would be helpful. I am also interested in a scheme for searching the database in regard to a group of different index parameters, ie, a list of all programmer’s who use a Macintosh, the C language, and are between the ages of 30 and 40. Efficient code for this type of a problem would be extremely educational.

Thank you very much for your assistance. Please continue the fine work which you and your staff have delivered.

[Yes, we have been laxed a little in the variety of languages covered in our journal. We have changed our article selection system to something that is hopefully more improved. But I get requests for more Fortran, more Lisp, more Assembly, as well as less on others. Any programmer worth his salt should be able to get information out of any language an application is written in even if it is not his preferred language (Jörg Langowski frequently has something very interesting in his column for me even though reading that Forth code is “reading hard”). I would also like to see more DB columns as well as WP, PS, and DTP. But unfortunately most of the articles I have on hand don’t fit into those categories. All those who have been thinking of writing up some articles with this much meat, get a typing!. -ed]

MyTENew Suggestion

Moshe Foger

I would like to comment about calling ROM directly through pointers published in the last September issue (Mousehole Report, p. 18). In my opinion the code would not work for the following reason:

When Lightspeed calls the MyTENew, it adheres directly to Pascal stack conventions (leaving room for TEHandle and pushing pointers to the two rectangles) and jumps to MyTENew leaving the return address on the stack. However in MyTENew, the compiler automatically inserts “Link A6, #0” which creates a new activation stack needed to access the function’s parameters. The link instruction saves the previous contents of A6 on the stack. The JSR instruction also leaves a return address on the stack; thus when the ROM is activated, it treats the saved A6 and the original return address as the required rectangle pointers and puts the handle in the pointer to ViewRect

To correct it, I would suggest the following in MyTENew:

TEHandle MyTENew(Dest, View)
Rect *Dest, *View;
{
asm{
 UNLK A6;Balance for Link from compilr
 MOVE (A7)+,A3 ;POP return addr. to safe reg.
 JSR  TENew ;Jump to ROM
 JUMP (A3); Return
 }
}

Animated Cursors

David Stoops

I am an engineering undergraduate at Drexel University, a school considerably devoted to Apple’s University Consortium. I am writing in response to the heated discussion of animated cursors in the March and May ’88 issues. In a rare moment of inspiration, I realized that animating the watch is a chore ideally suited for implementation as a VBLTask. Referring back to the June ’86 MacTutor, which contains an article on screen switching animation using the Vertical Retrace Manager, I wrote the enclosed snipets of Lightspeed Pascal code that seems to do the job.

The routines make use of the ‘acur’ resource, which should be copied along with the necessary ‘CURS’ resources from the Finder into the project resource file. To use these routines, first call InitWatch to get handles to the cursors, then call StartWatch to display the animated watch while your program goes on about its business. A final call to StopWatch removes the task from the vertical retrace queue to halt animation. I find this scheme does a better job of animating the watch than that emploed by the Finder (notice how poorly the watch hands move during lengthy I/O operations under the Finder). Hope this proves useful.

unit WatchGlobals

interface

type
 acur = record
 whichWatch : longint;
 Watch : array[1..8] of CursHandle;
 end;
 acurPtr = ^acur;
 acurHandle = ^acurPtr;

var
 currentWatch : integer;
 WatchList : acurHandle;
 VBL : VBLTask;

implementation

end.


unti WatchUtlities;

interface

uses
 WatchGlobals;

procedure InitWatch;
procedure StartWatch;
procedure StopWatch;

implementation

procedure InitWatch; {Get the watch CursHandles}
 var
 watchcount : integer;
begin
 WatchList := acurHandle(GetResource(‘acur’,0)); 
 {Will crash if ‘acur’ isn’t available’}
 with WatchList^^ do
 begin
 for watchcount := 1 to 8 do
 GetCursor(HiWord(longint(Watch[watchcount])));
 whichWatch := 0;
 end;
end;

procedure AnimateWatch; {Our VBL routine}
begin
 SetUpA5;
 with WatchList^^ do
 begin
 if whichWatch >= 8 then
 whichWatch := 1
 else
 whichWatch := whichWatch + 1;
 SetCursor(Watch[whichWatch]^^);
 end;
 VBL.vblCount :=10;
 RestoreA5;
end;

procedure StartWatch;
 {Install our task in the vertical retrace queue}
var
 err : OSErr;
begin
 with VBL do
 begin
 qType := Integer(vType);
 vblAddr := @AnimateWatch;
 vblCount := 10; {Update watch every 10 ticks}
 vblPhase := 0;
 err := VInstall(@VBL);
 end;
end;

procedure StopWatch;
{remove our task from the vertical retrace queue}
var
 err : OSErr;
begin
 err := VRemove(@VBL);
end;

end.