Dec 88 Letters
Volume Number: 4
Issue Number: 12
Column Tag: Letters
Happy Aniversary 
By David E. Smith, Editor & Publisher, MacTutor
Prototyper™ vs FaceIt™ vs Programmer’s Extender™
George R. Cossey
Author of Prototyper™
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.
Prototyper is definitely not perfect. There are many things I would like added or
changed. But this shows how much I like what Prototyper tries to do. I want to
improve what it does, not just throw it out. I can see in the future that this will be the
avenue of interface developing. The interactive feel of seeing your interface is very
gratifying. Mr. Cossey, please keep improving Prototyper. I feel you have a product
with lots of potential. -Kirk Chase, Assistant Editor, MacTutor]
Word 3.01 Word Wrap
Steve Seaquist
Temple Hills, MD
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
Bartlesville, OK
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
Tel Aviv, Israel
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
Philadelphia, PA
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
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.