Jun 89 Letters
Volume Number: 5
Issue Number: 6
Column Tag: Letters
By David E. Smith, Editor & Publisher, MacTutor
Language Systems Plans
Rich Norling
Herndon, VA
In MacTutor’s April letters column, Bert Waggoner added his name to the list of
those asking us to add a SELECT CASE statement to the Language Systems FORTRAN
Compiler. We are now making plans for Version 2.0 and I want to let your readers
know that SELECT CASE and NAMELIST are at the top of our list of new features to add.
Both will be done according to the FORTRAN ’8X syntax, so no changes in FORTRAN
source code will be needed when ’8X becomes a formal standard (let’s hope that
happens before the proposed standard has to be renamed ’9X!).
Additional suggestions for new features in Language Systems FORTRAN are
welcome. Please send them to us at the address listed in our ad (inside front cover).
Corrections
Don Koscheka
Arthur Young N0735
Joe,your article on adding windows to XCMDs was informative and, for the most
part, well written. Your discussion of scroll bars needs clarification. You state that
using ScrollRect to scroll a window is not the preferred approach because the window
will not get redrawn until update time. This is not true. While Inside Macintosh does
imply that you should pass the UpdateRgn of the current window to ScrollRect so that
the vacated area gets accumulated into the window’s invalrgn, this is not strictly
necessary. Consider the following code fragment:
Procedure TrackScroll( theControl : controlHandle; thePart : INTEGER
);
VAR
TempRgn : Region;
tempRect : Rect;
dh, dv : INTEGER;
BEGIN
{*** determine what part of the control we’re in... ***}
{*** and set dh, dv accordingly ***}
...
{*** now scroll the scrollable part of the window ***}
tempRect := theWindowsScrollablearea;
TempRgn := newRgn;
ScrollRect := ( tempRect, dh, dv, tempRgn );
SetClip( tempRgn );
{*** call whatever routine draws window contents ***}
Redraw_The_Window;
DisposeRgn( tempRgn );
...
END;
This code has the advantage of requiring only enough extra memory to store the
vacated region. Moreover, the novice programmer need not write any special screen
drawing code. Whatever code is used to draw at update time can be called directly to
redraw the window at scroll time. Since the window is clipped to only the vacated
region, this approach results in fast, smooth scrolling.
The more experienced user can query the region to determine exactly which
rectangle to update so that the application draws only what will be displayed in the
vacated rectangle. This is useful in applications like word processors where much of
the update time is spent calculating where things need to go on the screen.
Another interesting consideration is the possibility of creating universal scroll
bars. We accomplished this by having track scroll operate on a “scroll record” that
keeps track of all appropriate information relating to a given scroll bar. One of the
fields passed to the scroll record is the address of the routine to call in lieu of
“Redraw_the_Window” in the above example. The result is quite satisfactory: one
pair of scroll bars can be made to behave consistently regardless of the number of
window variations in a given application.
Thanks for the bent ear. Good luck at Apple (as a six-year veteran, I can tell you
that it’s a great place to work...)
CDEF Corrections
Kirk Chase
Anaheim, CA
It was brought up to my attention of another way to include CDEFs for debugging
purposes. James Plamondon, from Abacus Concepts, pointed out a better, more legal
(?), way of setting the contrlDefProc field of the control record.
const
JMP_Instruction = $4EF9;
JumpRec = record
instruction : integer;
function : Ptr;
end; {JumpRec}
JumpPtr = ^JumpRec;
JumpHdl = ^JumpPtr;
var
cdefJump : JumpHdl;
ctrlHdl : ControlHandle;
begin { Open_Example_Window}
{allocate and initialize jump record}
cdefJump := JumpHdl(NewHandle(sizeof(JumpRec)));
cdefJump^^.instruction := JMP_Instruction;
cdefJump^^.function := myCDEFProc;
{this ends initializing the jump record}
{get the control record}
CtrlHdl := GetNewControl(ButtonID, MyWindow);
{Set the contrlDefProc}
CtrlHdl^^.contrlDefProc := Handle(cdefJump);
end;
After diving into the tech notes, I also found what James already knew. James
also mentions that the control definition proc should be locked by keeping it in code
segment 1.
I appreciate James Plamondon help. The method I gave was essentially for
prototyping controls. This made development time faster since you could bypass the
Compile, ResEdit, Compile, Frustration loop. I hope Abacus realizes the asset James
Plamondon is. Thanks A Bunch.
MPW vs. LSC
Will Flor
Loves Park, IL
I thought I might give my views on the MPW vs. LSC controversy raging in the
March issue of your excellent journal, and also report a serious error in Jerry
Sweet’s otherwise excellent article on Ada.
In my last job, I developed finite-element modeling software on the Mac, and the
project was started in LSC. This type of software uses a lot of file I/O, and we had a
large set of routines known to work properly in several other environments (hundreds
of units shipped without a single bug report dealing with file I/O). Upon porting these
routines to LSC, they did not work. An examination of the problem showed the LSC
libraries to be bug-ridden and unmaintainable. The errors we were getting included
undocumented error codes being returned, “file not found” error code returned when
we tried to create a file, and more. After wasting nearly a day, we ported to MPW
2.0.2 and never had these problems. The Think technical support people were not
knowledgeable about their product, but admitted the sorry state of their libraries after
the erroneous source lines were pointed out to them. I have heard other similar
stories from other software developers, too. For very simple programs, perhaps LSC
works adequately; for true big-time software development it simply doesn’t do the job.
The “one segment per source file” restriction is untenable as well. I do not use LSC
and cannot recommend it to my clients.
Comparing MPW 3.0 to LSC is like comparing a turbo SAAB to a tricycle--they
do basically the same thing, and MPW (and SAAB) is arguably harder to learn to use
properly, but there’s an obvious difference in power and capability. MPW 3.0 is so
different from MPW 2.0.2 that it definitely warrants the upgrade fee, since it’s really
a totally different product--the C compiler is totally different, the Projector source
code control system is great (although it suffers from a few problems as well), and
everything is 25-40% faster. Perhaps a tricycle is more appropriate for some, but
I’ll take MPW and the turbo SAAB any day.
Jerry Sweet’s otherwise excellent article on Ada did contain one serious factual
error. He states that the MPW C “integer” data type is 16 bits wide--it is 32 bits
wide. The MPW C integral type that is 16 bits wide is “short integer” or simply
“short.” This is crucial to writing a correct interface subprogram since, as he
correctly points out, there is no data type cross-checking available, and it is easy to
pass the wrong parameter type.
Thank you, Mr. Smith, for editing such an excellent journal. Please keep up the
good work.
More On Compare Strings
John S. Stokes III
San Diego, CA
In Steve Brecher’s letter published in the March 1989 MacTutor, page 11, he
pointed out a bug in my “Compare Strings” routine in addition to suggesting some
improvements. I confess that I wrote the letter off the top off my head in response to
seeing some wasteful code. In looking at the actual code from programs I’ve written, I
do use the
Moveq #0,D0
Move.B (A0),D0
technique to load up the length for the compare loop.
I agree that using
;2
@0 Cmp.B (A0)+,(A1)+
DBne D0, @0
is much better than using
@10 Cmp.B (A0)+, (A1)+
Bne.S @900
Dbra D1, @10
and I thank Steve for pointing that out.
There is an error in his code if the comment “Return D0.L=1 if equal, 0 if not
equal” is to be taken seriously. Consider what happens to register D0 if the strings
compare equally. Register D0 will have a $0000FFFF after falling out of the loop.
Seq D0
will cause D0 to still contain $0000FFFF since the FF will replace the existing low
order FF. Executing
Neq.B D0
will cause D0 to contain $0000FF01 instead of $00000001. Ooops.
If the strings are not equal, D0 will contain $000000?? before the Seq
instruction and $00000000 after both the Seq and Neg.B instructions. This is OK.
The solution is to change the Neg.B to a Neg.W.
A re-corrected CompareString routine would look like this:
;3
;A0 -> Pascal String 1
;A1 -> Pascal String 2
;D0 Returns D0.L=1 if equal, 0 if not equal
;Alters A0-A1
CompareString:
;4
Moveq #0,D0
Move.B (A0),D0 ;gross length - 1
@0 Cmp.B (A0)+,(A1)+ ;loop until
DBne D0,@0 ;not equal or end
Seq D0 ;$0000ffFF if equal, else 0
Neg.W D0 ;1 if equal, else 0
Rts
Also, Steve did err in saying:
“Ext.W propagates the value in bit 15 of the register through bits 1631.
Therefore, it will not have the desired effect of clearing bits 815. Ext.B would not
work either for cases in which the string length is greater than 127, i.e., negative
considered as a signed byte; in such cases Ext.B would set bits 815, making the
unsigned word value very large.”
There is no “Ext.B” instruction. Ext.W does what was ascribed to Ext.B; Ext.L
does what was ascribed to Ext.W. So my Ext.W instruction did have the desired effect
as long as the string length was less than 128.
Correction to Correction to CompareString
Steve Brecher
Sunnyvale, CA
John F. Reisor’s letter (Apr. 1989) correcting John Stokes’s original (Jan.
1989) made me realize that my own correction (Mar. 1989) was incorrect! Reisor’s
code contains an error also.
My submission omitted an Ext.B D0 instruction just before the final Rts. Reisor
uses Ext.W D0 where there should be an Ext.B D0.
Since this issue of conditioning bits 8..15 of a register has tripped up three of
us, perhaps a review is in order. Ext.B sets each of bits 8 through 15 of a register to
be equal to bit 7; it does not affect bits 0..7 or bits 16..31. Ext.W sets each of bits
16..31 to be equal to bit 15; it does not affect bits 0..15. In other words, Ext.B
extends the sign of the low order byte through the high order byte of the low order
word. Ext.W extends the sign of the low order word through the high order word.
Note that where I wrote
Seq D0
Neg.B D0
Reisor wrote instead
Sne D0
AddQ.B #1,D0
which is equivalent.
My routine and Reisor’s, after correction, are both the same length. But any
Macintosh assembly language programmer should be able to come up with a version
that is one word shorter--left as an exercise for the reader. For those who wish to
try, here is the final “long” version:
;5
; A0 points to a Pascal string
; A1 points to a Pascal string
; Returns D0.L = 1 if strings equal, else 0
MoveQ #0,D0
Move.B (A0),D0
@0 Cmp.B (A0)+,(A1)+
Dbne D0,@0
Seq D0
Neg.B D0
Ext.B D0
Rts
Claris CAD
Kirk Chase
Anaheim, CA
Claris has added another fine product to their line, Claris CAD. This is a fine CAD
product, specifically designed to take advantage of the Mac and its graphic capability.
This high-end product follows the trend of others by including a videotape for learning
the program’s capabilities rapidly. It has a complete set of two-dimensional tools for
design and drafting professionals. It also allows for changing dimensions and units.