Jun 90 Letters
Volume Number: 6
Issue Number: 6
Column Tag: Letters
Parse Table Correction
By Kirk Chase, Editor, MacTutor
Parse Table Correction
Kirk Chase
MacTutor
Unfortunately, Clifford Story’s second part in his Language Translation Series
was missing the parse table. Here it is for you now:
Dialogs, the easy way
Neil Ticktin
Truin Software
I was glad to see that dialogs are now getting some press. I wanted to make sure,
though, that your readers connect dialogs with Extender DialogHandler™ by Invention
Software. First, there is a review by David Kelly on DialogHandler in the January,
1990 issue of MacTutor.
In the April, 1990 article on extending modal dialogs, Paul Potts talks about
default bold outlining, key equivalents and default items.
DialogHandler takes care of all of these things automatically for you. In your
article on Messenger, you speak about placing dialogs, icons, multiple buttons,
character equivalents, and adding filters. Again, DialogHandler takes care of all of
these things as well -- all automatically. In short, DialogHandler handles push
buttons, multiple sets of radio buttons, check boxes, counter items, icons and pictures
with animation, display text items, pop-up menus, pull down menus, “pick lists”
(list manager style), and string, integer, long integer, and real “flavors” of edit and
static text. All number conversion, on-the-fly character filtering, cut/copy/paste
support, and key equivalents are taken care of automatically.
DialogHandler now supports modeless dialogs. In addition, almost every item can
have a “user hook” associated with it. In other words, if you want a push button to do
something special, you can write a procedure to do that and pass a pointer to that
procedure to DialogHandler. DialogHandler, in turn, will call your routine when the
item is hit.
For example, take a simple dialog that asks for an integer between -100 and
100, has a bold outlined OK button, a Cancel button, on-the-fly character filtering
(the user can’t enter a bad character), full cut/copy/paste support, range checking
with alert and handling of the ok and cancel buttons. Using DialogHandler, you can
write the support code for this dialog with 6 lines of code.
In summary, if you are doing dialogs, modal or modeless, you can do them in
5-10% of the time using Extender DialogHandler™ from Invention Software at
313-996-8108. It will pay for itself on the first dialog. As you already may know,
MacTutor is also selling DialogHandler in the mail order store.
MultiFinder Detection
Ajay Nath
Oakland Gardens
Daniel Allens excellent book, “On Macintosh Programming: Advanced
Techniques”, shows a quick way (on p. 160) to find out if MultiFinder is running.
Simply examine the long word at $B7C which is called “Twitcher2”, if its less than 0
then MultiFinder isn’t running. I have a feeling that somebody at Apple didn’t read his
book too carefully since I don’t think they’d want us to know this.
cdevShell
Charles Dyer
Jamaica, West Indies
I am writing about that cdevShell.p article in February, 1990 MacTutor. I
finally got it all entered and tried to test it out, but then I founddrumroll,
pleaseBUGS. Some of them were typos, but those were easily fixed. However, I still
get the ever-popular ID=2 and ID=28 bombs even after I had corrected all of my
spelling errors. So I used TMLPascal’s TMLPasRef utility to try to track who did
what/where, and guess what: a lot of items are initialized but never used. In
particular, the variables totalItems, p, c, tempD, and r in the procedure startupCdev
are never used anywhere. It appears that a line or two may have been left off. And
those were only the more obvious and easier to find examples. After I found them, I
went through the source checking every case where PasRef said that a variable had
been used once, and found several others. I also checked the .r file, and noted that there
doesn’t seem to be a DLOG or an ALRT for DITL -15999.
Tracking would have been easier if only Mr. Hoddie hadn’t used so many cryptic
variable names. I mean, in startupCdev the variable c is of type ControlHandle. A
little further on, there is another c which is an INTEGER. Would it have been so
difficult to use theControl and counter, respectively? The whole programme is
peppered with single-character variables: e, i, j, p, r I haven’t seen so many
single-character variables in one place since I stopped using BASIC on an Apple II.
Variable names like dP, tempD, and rH don’t help either. It’s not so bad if the thing
works right the first time, but
In the past, if I had a problem, when I translated a program over from Pascal to
Modula-2 and things didn’t work, I wouldn’t know if it was because so obscure
difference between Pascal and Modula-2 or if it was just that I did something wrong.
Thanks to TML, if it doesn’t work and I can’t find any difference between my code and
what’s in the magazine, I’d say something is wrong with the published code. In any
case, I’ve gone through my code several times and cannot see where I’ve gone wrong. It
might still be something I did, so I’ll try again, but in the meantime, I’d like to know if
anyone else has had any problems with cdevShell.p.
I now use TML Pascal II, as SemperSoft seems to have bitten the dust. I would
like to get another Modula-2 package, but no-one else seemed to have an MPW
Modula-2 package available. Having shelled out all that cash for MPW in the first
place, I am not going to give up on it without a fight. I’ll even get C-ugh-if I have to.
Actually, what with UNITs and some of the other extensions, TML Pascal is almost
Modula-2 anyway. The .o and executable files that TML makes are a little bigger than
those made by SemperSoft Modula-2, but TML is faster and doesn’t give weird
problems when you’re trying to build cdevs and INITs. The biggest problem so far has
been the Show Icons LDEF demo program from the TML Source Code Library crashes
and burns under MultiFinder. I haven’t gotten around to writing them about that yet.
[I have check the printed code against the original source code, and I could not see
a line missing in startupCdev. I have had no complaints, other than yours, about
cdevShell.p. I ask if anyone else has to write a letter to MacTutor. On the good side,
Metrowerks has Modula-2 for MPW at $150. Their phone number in the USA is
514-458-2018; their FAX number is 514-458-2010.-ed]
MPW Pascal Compiler
Richard H. Winkler
Boulder, CO
We have discovered a bug in the MPW Pascal compiler which has remained
constant from version 2.02 through version 3.1. The bug arises when the stack frame
in a procedure exceeds 32k bytes in size. Two Pascal programs used to test this bug
differ only in stack frame size, the program ‘lgstkfrmst’ had added to it a second
array, z2: ARRAY[1..7000] OF REAL, which caused the stack frame to grow beyond
32k. As one would expect, the addressing strategy for all stack frame variables which
are normally addressed indirect through A6 is altered such that A6 is moved to A0, the
variable offset is added to A0, and the variable is then addressed indirect through A0.
The assembly code produced from ‘lgstkfrmst’ produces an instruction:
;1
PEA $252A(A6)
which should in fact be the set of instructions:
;2
MOVEA.L A6,A0
ADDA.L $FFFF252A, A0
PEA (A0)
This is a particularly unusual error in that the lower half of the address is
correct. Had the compiler used proper (A6) addressing one would have expected
something other than $252A. In particular one would have expected -$6D6C as in the
assembly listing of ‘smstkfrmtstcd’, the smaller stack frame test code. This error is
believed to occur following calls to transcendental function other than _LN.
As a historical note, let me add the following. I suspect that what is now the MPW
Pascal compiler was originally developed by Silicon Valley Software for earlier
68000 based machines. In particular, I believe that this was the same Pascal
compiler used for the ill fated IBM 9000 computers. I have worked extensively with
9000’s and base this conclusion on the fact that the manual included with version 2.02
of the MPW complier was word for word identical, down to the page breaks, with the
Pascal manual supplied with the IBM 9000. With the 9000 compiler, we also had a
compiler bug associated with the stack frame growing beyond 32k bytes. In particular
there was a range of stack frame sizes from 32000 bytes to somewhere greater than
32768 bytes where the stack frame pointer, A6, was set point to the load point of the
system library rather than to the stack frame when a subroutine was entered. This
bug was fixed by IBM (Silicon Valley Software?) in version 2.0 of the compiler, but I
find it an interesting coincidence that the MPW compiler has a bug which arises under
similar circumstances surrounding the stack frame.