Feb 89 Letters
By David E. Smith, Editor & Publisher, MacTutor
Invention Software Programmers 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 Programmers Extender user (Warren Michelsen) listed a number of problems he was having with his Programmers Extender libraries as well as our response to his inquiries. Invention Software does acknowledge that there was a problem with the resizing of a TextEdits 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 TextEdits 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. Michelsens 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. Michelsens 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 Extenders 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
Another weekend, another thought about Event Simulator. This thought is a minor one, though, and Im not even sure if its 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 thats done this kind of thing before has probably used PPostEvent. Why didnt you use PPostEvent? Dont you have a copy of Inside Mac IV? Its easy. Heres how The disclaimer above explains why I didnt 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
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]
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 dont 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 lets have even more thought provoking articles in MacTutor! [Well 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 dont care if MultiFinder is around. - KC]
Animated Watch Cursor Typo
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
watchcount : integer;
WatchList := acurHandle(GetResource(acur, 0));
with WatchList^^ do
for watchcount := 1 to 8 do
Watch[watchcount] := GetCursor(HiWord(longint(Watch[watchcount])));
whichWatch := 0;