Feb 89 Letters
Volume Number: 5
Issue Number: 2
Column Tag: Letters
By David E. Smith, Editor & Publisher, MacTutor
Invention Software Programmer’s Extender
The Resolution !!!
Dale C. Quantz
The following letter is the response to a letter published in the October 1988
issue of MacTutor. In this letter a Programmer’s Extender user (Warren Michelsen)
listed a number of problems he was having with his Programmer’s Extender libraries
as well as our response to his inquiries. Invention Software does acknowledge that
there was a problem with the resizing of a TextEdit’s destination rectangle when using
either the zoom or grow boxes. This bug ONLY occurs in the LSP version of the
Extender Volume 1. The bug was inadvertently introduced when a user requested code
that would resize a TextEdit’s destRect during a zoom or grow operation. Prior to this
we had told other users to implement this feature in the UserHooks (named: UserGrow
& UserZoom). After sending a piece of code to a user who was having trouble
implementing the above mentioned functionality, the code was accidentally integrated
into the LSP release versions. Up until Mr. Michelsen’s letter (he did not telephone
us) we were unaware of the problem. We attempted to reproduce his reported bug and
were unable to do so. We had not been aware of the problem and/or could not produce
the desired affect. We then informed Mr. Michelson that we could not reproduce the
bug. It was not until Mr. Michelsen’s second correspondence that we were able to
reproduce the problem. The bug appears to have become more pronounced in the later
system versions (most likely because of the numerous bug fixes to TextEdit).
In any case, we have completely rewritten the text editing in the Pascal Extender
versions and have sent Mr. Michelsen a version of the Extender with the latest code. If
any other users are encountering similar problems with the Extender’s
implementation of TextEdit (apart from the 32,000 character limit which is inherent
in TextEdit) please contact our technical support staff between the hours of 8:30am -
5:00pm EST.
Update to Event Simulator
Matthew Snyder
Fairfield, CA
minor one, though, and I’m not even sure if it’s significant enough to merit a change.
[This letter refers to a program published in the January 1989 issue of MacTutor.
-Ed]
The change would be a minor one, too. Right before the heading How the Demo
Works and right after that long paragraph about memory, I would add this paragraph:
"I could have avoided the memory problem by using PPostEvent instead of
Enqueue. PPostEvent takes an event type and message as arguments, and creates an
event using current mouse position, modifier keys, etc., posts the event, and returns
to you a pointer to the new queue element. You can then use that pointer to modify the
event to your liking. However, I found this method unsatisfactory for a general
library because the size of the Event Queue Buffer limits you to 20 consecutive
events.
I was trying to imagine what type of critical letters I could expect from readers,
and it occurred to me that anyone that’s done this kind of thing before has probably
used PPostEvent. “Why didn’t you use PPostEvent? Don’t you have a copy of Inside
Mac IV? It’s easy. Here’s how” The disclaimer above explains why I didn’t use
PPostEvent.
[Thank you, Matthew, for your update. Matthew is one of the more concientuous
writers, always thinking about his article, even after it has been submitted.
Unfortunately, this letter came to me just as I was proofing the final proofs of the
journal. -KC]
MacFortran/020 Math Library
Tatsuhito Koya
Evanston, IL
Being a student, I have been on a tight budget lately. I had to terminate most of
my magazine subscriptions, but I have decided to keep MacUser, Computer Shopper,
and MacTutor. These three magazines have been the main sources of information about
what is happening in the world of personal computing--the world of the Macintosh,
specifically.
I am not a computer science major; hence, it is difficult for me to find time to
develop my programming skill, yet I do have opportunities to use computers for
engineering computations. I do most of my computations on the main frame, but I
would really like to use my Mac as well. I have MacFortran/020, but the problem is
that I cannot find a math library for it anywhere. Moreover, Edit text editor is not one
of the best program editors around. I would really appreciate it if you could
recommend me a good math library (modifiable preferred) and a program editor.
[ I called Absoft to check on the math library; unfortunately, they knew of none,
but they seemed to like the idea; maybe our readers know of a library out there, or
will create one. -KC]
[As for a text editor, I would suggest a new Fortran specific editor called
FREDITOR 1.0 from Battelle Pacific Northwest Laboratories, PO Box 999, Richland,
WA 99352. Our good friend Bill Rausch wrote the manual. The editor was written in
Lishgtspeed C and used the LS CAPPS Editor construction kit. The product is distributed
by TechAlliance. Look for it in MacTutor's Mail Order Store real soon now. -Ed]
Lawrence D’Oliveiro
Hamilton, New Zealand
I read the articles on the IAC driver by Frank Alviani and Paul Snively with great
interest. The Mac certainly needs a capability like this. However, a couple of
questions.
First of all, why does the driver need to save multiple editions of a source
extent? It only returns the latest one on any ReadData call anyway.
Secondly, it would be useful to allow desk accessories to take advantage of IAC.
And of course, you don’t need MultiFinder to run desk accessories. The check for the
presence of MultiFinder is neat, but is it really necessay?
As always, keep up the good work, and let’s have even more thought provoking
articles in MacTutor! [We’ll do our best. -ed]
[This letter gave me the excuse to call and talk to Frank Alviani. Frank, if you
ever get the chance, is one of the nicest people to talk to, and I enjoyed the opportunity
to call and see how things were going on his new house (not done as of this writing).
Frank explained to me that although the main purpose of the driver is to give the
most recent extent to the clients, there are a couple reasons to keep the old extents.
The first is to give the client the ability to call older extents. This could be used for
perhaps a “hot” undo feature.
The second reason is useful for database type applications where each extent may
want to be saved for future use. Lengthy file operations may bring the client back in
time to find himself several extent versions behind the current version.
Your second question was a good one, also. Desk accessories have the ability of
file I/O. Also the driver itself makes ordinary calls. Therefore it is conceivable that
the driver could be modified to work with desk accessories. The call to initialize the
driver could say basically, “I don’t care if MultiFinder is around.” - KC]
Animated Watch Cursor Typo
Andy O’Brien
Keep up the great work on a fine magazine. Even the letters contain little tidbits
of information. I e specially enjoyed David Stoops’ letter in the December ’88 issue.
After keying it in (and getting the proper LSP error message). I Realized that the
InitWatch procedure in the WatchUtilities unit had a typo in it. GetCursor was being
called as a procedure when we all know it is a function. Here is what the procedure
should look like. Take care and continued success
porcedure InitWatch;
var
watchcount : integer;
begin
WatchList := acurHandle(GetResource(‘acur’, 0));
with WatchList^^ do
begin
for watchcount := 1 to 8 do
Watch[watchcount] :=
GetCursor(HiWord(longint(Watch[watchcount])));
whichWatch := 0;
end;
end;
Bookstore Blues?