Nov 86 Letters
Volume Number: 2
Issue Number: 11
Column Tag: Letters
Bugs to Watch Out For
David Smith, Editor
One of our readers brought to our attention, a glitch in Pagemaker that caused a
line to disappear at the top of a column in the September issue of MacTutor in the
"Pop-Up Window Scroller" article by Scott Boyd. At the top of page 51, left side
column, the following line vanished on the LaserWriter output:
baseAddr:= QDPtr(NewPtr(sizeOfOff));
The following lines are "rowbytes:=offRowBytes" and "bounds:=bitRect;", which
are ok as printed. Also, in the same column and page, watch out for another Pagemaker
goof; the minus sign is printed way to the right of the column on the variable
"-underRect.top" in the procedure OV_RestoreBits and might be easy to miss. Neither
of these two problems show up on the screen; only on the Pagemaker output. We regret
that we did not catch these problems. We assumed that Pagemaker knew how to print
correctly, an assumption we are finding is not always correct.
Random System Crashes: SCSI Drives or Mac OS?
We recently purchased a Data Frame SCSI hard disk here at MacTutor and have
been very happy with it so far except we have had a large number of random system
crashes. Our system file is running about 550K and the disk is full to 17 Megs, with a
Max2 2 meg memory upgrade. We can't tell if this is a problem with the Data Frame, the
memory upgrade or the Mac. The crashes run two or three a day, in the middle of
MacWrite or when trying to do a SAVE, and seem to have no pattern. We consulted with
John Theurich at Coast Computer in Costa Mesa, CA. He is of the opinion that the random
system crashes, which he has also observed in his system with a number of SCSI hard
disk products, are due to a large system file with many fonts and DAs. He has found that
reducing the number of fonts and DAs in the system file eliminates the random system
crashes. This has been confirmed by some of his customers as well. If this is so, then it
would appear that Apple's own software can't keep track of itself, and one of the main
reasons for having a hard disk, for extra fonts, is unavailable! We find this very
disturbing! If any MacTutor readers have any ideas or experience along these lines,
please communicate them to us by phone or in writing so we can get a survey of how
widespread this problem is and who is the culprit behind the problem. We have reduced
the fonts and DAs, but the system crashes continue. We are now trying other Macs
without the memory upgrade.
Another possibility is the menu snapshot fix for the cmd-shift-3 function key.
The fix published in MacTutor in the August issue of MacTutor seems to foul up the
menu manager because it calls GetNextEvent. The event loop and the menu manager are
very closely tied together. We have observed some unusual font changes in dialog boxes
after printing that seems related to this fkey fix. We recommend not using the fix we
published. Instead, we have tried the Apple installer script that also fixes the menu
snapshot problem but without the menu manager problems. We have since removed that
init function also while we track down the cause of the random system crashes.
Apple - DEC Link
Kinetics Inc. has come up with hardware to link Apple and DEC networks. Their
$2500 FastPath / Standalone is a programmable gateway between AppleTalk and
Ethernet, letting computers share common applications. The $1800 FastPath / Q-bus
is an AppleTalk controller board for Q-Bus backplanes, dual-height, allowing DEC's
MicroVAX to use Apple's LaserWriter and other peripherals over AppleTalk.
Some software support for VMS, UNIX and Ultrix operating systems is already
available.
For VMS: AlisaTalk from Alisa Systems (Pasadena CA) lets VMS/VAX systems
provide transparent file services and LaserWriter print spooling for Macs, connecting
VAX-based apps to the LaserWriter for printing of PostScript docs. [Note: This is Bob
Denny's company and is the result of work he has been doing for Apple for the last year.
-Ed] Helix/VMX data-based applications environment from Odesta (Northbrook IL)
gives multiple Macs network access to VAX-based info processing and storage.
For UNIX and Ultrix: TOPS from Centram Systems West (Berkeley CA), a
distributed file server that also links IBM PC systems, provides client and server
functions. Ultra-Office from LBA (Culver City CA) office productivity & info mgmt
system has mail service, terminal emulation, file library, disk server and print
spooler functions. Two from Kinetics: K-TALK software implements AppleTalk
protocols for Ultrix and UNIX including programmers' libraries, and K-Term, a
multi-window terminal emulator gives Macs VT100-like terminal access via
AppleTalk.
C Here
Jason De Mont
MiddleTown, NJ
I recently acquired a June '86 copy of MacTutor and found it to be very
worthwhile. I have a Mac+ and Lightspeed C, and e specially enjoyed Bob Gordon's
article. Please print tutorial articles on C, the toolbox interface and using utilities
such as Resource Editor and FEdit. P.S. Keep up the good work!
Keyboard to Quickdraw
William Dellal
New York, NY
I am trying to use TML Pascal to write some utility programs but am having
difficulty writing a procedure that allows keyboard input into a regular Quickdraw
window. In other words, I want to create a "read" function for the keyboard that will
operate in a regular window as opposed to the "plain vanilla" mode of TML Pascal. I
know that I can intercept keystrokes using the Eventloop, but then I have trouble
backspacing and echoing the characters properly. I believe that something can be
worked out using Textedit procedures, but I have not been able to master them. [I
suggest you see the Keyboard Slueth article in the August issue of MacTutor. And the
multi-window text editor in this issue. -Ed.]
Programming Editors
The Midnight Hacker
Somewhere in Florida
Speaking of programming editors, I've tried Edit, QUED, Fast Eddie, and MEdit.
Fast Eddie 2.1 is mostly weird, e specially with the menus. QUED 1.5 has many useful
features, including good window handling and split screens, but QUED cannot integrate
with Mac C (it crashes!) MEdit 1.5, which is shareware for $25 is a great macro
editor. It's a little weak in window handling, but the author Matthias Aebi, who lives in
Switzerland, says he's going to improve that in the next version.
TML 2.0 Compiler Bug Workarounds
Michael T. Brand
Torrance, CA
Having just spent the last week updating my latest development effort (>5000
lines of Pascal) from TML Pascal v1.0 to v2.0, I thought a few of your readers might
be interested in a few apparent compiler bugs and workarounds I discovered in the
process.
1) The compiler sometimes reports an error indicating that a referenced
subroutine was not completely defined. The error message is 'Forward declared
subprogram "name" not completed in previous block'. The referenced
subprogram is often one which is in a unit 'used' by the routine being compiled.
This error seems to be sensitive to the calling order of subroutines defined within
and outside the unit being compiled, or on the ordering of some lines. This
appears to be a false error indication, and can be ignored. I've found that it's
possible to configure the program to eliminate the problem, but it can take hours
to find the lines the compiler finds offensive. I've included a sample program
which exhibits the problem.
2) The case function has a problem if the selector expression is anything other than
a simple variable or constant. If the selector is a function result or even a
compound expression such as
var a,b : boolean;
:
:
case a and b of
:
this line will cause a system level bomb, typically with system error ID+10, a
divide by zero. To work around this problem, simply compute the complex
expression to using the result in the case statement.
3) TML Pascal v2.0 introduces a new function which is intended to mimic the
Toolbox function BitAnd (and unfortunately uses the same name), in a more
efficient manner. This function does not work properly with a longint type of
variable. In the following expression
var a,b : longint;
:
:
a :=BitAnd(b, $FFFFFF00);
:
the upper half of a will always be zeroed, independent of the value of b. A simple
way around this is to use the Toolbox function BitAnd. However, note that the
InLine expression for this function (as well as BitOr, BitXor, and BitNot) is not
in the MacIntf.pas source file. They must be added to this file (or your own file).
Their associated trap addresses are $A858, $A85B, $A859, and $A85A,
respectively. I renamed them BitAnd0, BitOr0, BitXor0, and BitNot0 in order to
distinguish them from the Pascal versions. I have not tested the functions BitOr,
BitXor or BitNot.
4) The compiler directive '{U<' is intended to allow libraries to be linked to a new
segment, rather than the same segment, as with the '{U' directive. The compiler
does not seem to distinguish between the two directives, however, interpreting
'{U<' the same as '{U', and therefore it does not add the 'new segment' symbols to
the link control file. A simple workaround for this is to replace each line of the
form
{U< libraryname}
with the two lines
{U<}
{U libraryname}
This will add the appropriate symbols to the link control file.
I don't pretend to have done a thorough review of the version 2.0 update, but
these modifications got my program humming along again. I've spoken with Darryl
Lovato at TML about these problems and sent him a copy of this letter.
This one compiles ok:
unit unitA;
INTERFACE
procedure routineA1;
IMPLEMENTATION
procedure routineA1;
begin
end;
end.
This one compiles ok too:
unit unitB;
INTERFACE
uses unitA;
procedure routineB1;
procedure routineB2;
IMPLEMENTATION
{---------------------------------------------}
procedure routineB1;
begin
end;
{---------------------------------------------}
procedure routineB2;
begin
routineB1;
routineA1;
end;
end.
This one generates a compiler error:
unit unitC;
INTERFACE
uses unitA;
procedure routineB1;
procedure routineB2;
IMPLEMENTATION
{--------------------------------------------}
procedure routineB1;
begin
end;
{--------------------------------------------}
procedure routineB2;
begin
routineA1;
routineB1;
end;
end.
This is the error:
unit C.pas
28 end.
^1
(1) Forward declared subprogram "routineA 1" not completed in previous block.
Stolen Update Events Returned
Peter J. McInerney
Auckland, New Zealand
This is just a short note to clear up a fundamental misconception about the
handling of updates that appears in Scott Boyd's "Pop-Up Window Scroller" (Vol 2 No
9). He says that he wants to prevent OverViewSelect being called if there are any
pending Update events for the front window. He says this is accomplished "By doing a
BeginUpdate and an EndUpdate for FrontWindow", and sure enough that is what appears
in the program, commented as stealing the update events. It does nothing of the sort (in
fact it does nothing at all, practically speaking). According to Inside Macintosh
"BeginUpdate replaces the visRgn of the window's grafPort with the intersection of the
visRgn and the update region and then sets the window's normal VisRgn". Disassembly
of these routines in ROM reveals that this is exactly and only what these routines do.
They do nothing to the event queue and do not even require that an update event has been
previously posted. You could for example call your Update routine at any time to
redraw your window, without passing throught the event loop, provided the update
region had been altered to reflect the region required to be redrawn (there is no
particular reason to do this, by the way). A further consequence is that if the window
to be updated is genuinely the front window, then omitting the BeginUpdate and
EndUpdate should have no visible effect when the window is redrawn (again this is not a
suggestion).
Since Scott's program works, either his argument about updates for the
frontwindow is wrong or he has been lucky so far. Assuming he has been lucky, how
could he steal the update events as required? There are at least two methods that would
work. One way is to call FlushEvents with a mask set just for Update events. In the
circumstances of this program I don't think any problems should arise, but the
possibility exists (because of their low priority) that update events for other windows
might be erroneously discarded. Another method, which avoids this problem, is to
InvalRect the portRect of the window and let the events take their course. In fact, it is
almost certain that neither of these actions is necessary. Update events are primarily a
mechanism for the window manager to handle overlapping windows, and unless you are
moving windows around, you have to work hard (with InvalRect and InvalRgn) to
generate them. I don't think there are any Quickdraw routines that by themselves
generate updates or change the update region of a window (if anyone knows differently I
would like to know). ScrollRect seems at first glance to be an exception, since one of its
parameters is given as a region called updateRgn. But this is not the update region of a
window (unless you say it is) and is merely the region you may wish to update (using
InvalRgn) if you want. This last point seems to have confused more than one person. I
recall seeing an example program (I think from Apple) in which the updateRgn which
didn't need to be redrawn after a ScrollRect was operated on by a ValidRgn to "increase
performance".
I hope the above clears up the mystery somewhat.
Mouse Droppings Editor
Phil Russell
Referenced by (2):