Feb 89 Letters
| Volume Number: | | 5
|
| Issue Number: | | 2
|
| Column Tag: | | Letters
|
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
Another weekend, another thought about Event Simulator. This thought is a 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]
IAC Driver
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 especially 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?
