Text Views
Volume Number: 7
Issue Number: 7
Column Tag: Jörg's Folder
Text Views and Forth News 
By Jörg Langowski, MacTutor Editorial Board
“Multiple text views in MacApp”
First, I’d like to give the Forth users among you some good news and some bad
news. The bad news first. Mach2 doesn’t work with System 7.0, and I can’t get hold of
Palo Alto Shipping. If anyone of you out there knows how to contact them, if they’re still
alive, etc., please drop me a note (Netland: langowski@frembl51.bitnet or
langowski@embl-heidelberg.de, Applelink: langowski.j).
The good news is about Neon, the OOP Forth implementation by Kriya Systems.
You might remember that Bob Loewenstein from the University of Chicago recently
managed to persuade Kriya Systems to put Neon into the public domain - under the name
of Yerk. Well, since then he has not been asleep and has made some improvements, right
now we’re at Yerk version 3.3.2. Instructions on how to obtain the Yerk files are in the
letter that arrived recently over E-Mail:
From:
Bob Loewenstein
Subject: yerk 3.3.2 upgrade
An upgraded version of Yerk, the Object Oriented Forth for the Mac, is available for
anonymous ftp on oddjob.uchicago.edu, in directory ~ftp/pub/Yerk.
If you already have version 3.3.0, you need only ftp the ‘upgrade.sit.hqx’ file. If you do
not have a previous version, ftp the complete package in file ‘yerk3.3.2.sit.hqx’. The
manual has not been changed.
The basic changes from 3.3.0 are:
COSMETIC CHANGES
- revised bold fonts in // so 9 pt chicago not loaded
- class window now erases grow box when grown
- now cursor is erased with delete key if +curs is set
- slight cosmetic change to (.mod)
- slight change stop: timer
- ?lines changed in nuc to keep bottom line on screen
and grow: method in window changed to send current
line to bottom if grow shortened window.
BUG FIXES
- modified savesig
- added negate: to class Int
- fixed slight bug in decompile (for floats)
- fixed to: problem in pathList source for sarray (file
pathlist)
- some changes to Install Module..it still does not
create a stand-alone application, but does reset
dictionary and stack sizes
- slot manager traps now correct
I would appreciate a note from anyone who intends to seriously use this development
system. Future upgrades will be forthcoming, and any reasonable suggestions will most
likely be included in such upgrades.
Bob Loewenstein
Dept. of Astronomy and Astrophysics
University of Chicago
Yerkes Observatory
Williams Bay, Wisconsin 53191
414-245-5555
As usual, I’d be glad to help those who have difficulty downloading the Yerk
source over the network. Drop me a line at one of my E-mail addresses.
The second good news comes from Michael Hore (Australia), of Mops fame (Mops
= Michael’s object programming system). To remind you: Michael re-implemented
Neon on top of a subroutine-threaded Forth kernel, with lots of inline code and other
optimizations. A couple of days ago, his letter arrived:
Dear Jörg,
I was really please with the glowing report you gave about Mops in MacTutor of
Oct last year. Several people in various parts of the world have since contacted me for
copies of Mops. This is to let you know that I am just putting the finishing touches to
Mops 2.0, and expect it to be available in a couple of weeks now. Actually I am aiming to
have it available by the time Apple releases System 7, but I think I might beat them to
it (wouldn’t be too hard, would it?) [well, it seems once in a while Apple gets
something out on a deadline - which has been pushed far enough, however. I remember
MacHack 1989 when they were taking bets when System 7 was going to be released, Fall
89 or Spring 90, etc - JL].
With Kriya’s release of the source code of Neon, I am now free to offer Mops to
anyone, not just Neon users. Although to really make it accessible to non-Neon users I
should probably write a manual (ugh!).
Actually I note that the text of Kriya’s letter to Bob Loewenstein says that Neon is
released for “scientific and educational purposes All commercial distribution rights
are reserved by Kriya Systems, Inc.” This, of course, isn’t exactly public domain. It
means that if a non-Neon owner wanted to do something commercial in Mops, and Mops
still contained any of Kriya’s source code, I would have to negotiate a separate
agreement with Kriya, somehow
Still, to be realistic, I doubt that any non-Neon owner would want to use it for a
commercial project at this stage, although there is a Neon owner here in Australia who
is going to use it commercially. Eventually there will be none of Kriya’s code left, and
then there will be no problem. The nucleus and most of the standard system stuff is
original right now - only the language itself is closely derived from Neon, and my
understanding of the legalities is that a language, as such, isn’t copyrightable.
Anyway, this release will have quite a number of improvements:
• Mops will be fully System 7 friendly. All the new system calls will be available
through the normal Call xxxx syntax. (I’ve discovered, incidentally, that Neon
won’t run under System 7 - there’s a problem with the way it resizes itself in
memory on startup).
• Up to 24 named parameters/local variables. This used to be 6 in Neon, 5 in Mops.
• The Assembler will support the 68881/2 FPU instructions.
• Mops already has Neon-compatible floating point - in the new version, FP words
test a flag for the presence of an FPU, and if it is present, these words bypass
SANE. This gives around a 400% speedup. Mops will also optionally compile inline
optimized FPU code. If this mode is selected, up to 6 floating point named
parameters or locals will be kept in the FPU registers. This results in some
rather swift floating-point code (10 to 20 times faster than SANE). This is
probably as quick as anything on the Mac, if not quicker.
• No limit on dictionary size.
When this version is available I’ll send you a copy, which you can distribute
[Sure will! - JL] or whatever. As always, anyone who sends me two blank disks will
get a copy (or if they put something else useful on the disks, I won’t complain).
Yours sincerely,
Michael Hore
(c/o MAF, P.O. Box 821, Nhulunbuy, NT 0880, Australia)
So you see, the OOP Forth scene for the Mac isn’t anything like dead, but quite a
few exciting things are still happening! If you are using any of those systems and have
an idea for an article, I’d really appreciate your contributions.
Multi-box text editor
Now let’s go back to C++, MacApp, and this month’s main subject. We’ll extend
the simple editor from the May column to accommodate several boxes containing some
text, of different style. We also want a border drawn around each box, and the window
in which the text boxes are displayed should be scrollable (you notice that with these
additions we come closer to adding a ‘text box’ capability to our drawing example).
Anything that is to be scrolled in a MacApp window will be contained in a scroller
view (class TScroller). This time we shall create the scroller from a view template
that we define with ViewEdit; the scroller will contain two subviews of class TTEBox.
This class is derived from the standard class TTEView. It implements its own Draw
method which draws a box around the view, and a DoMouseCommand method which
handles mouse clicks in the view.
The latter method is important for selecting the text box which will receive the
keystrokes typed by the user; clicking in one text box should select that box (this is not
an automatic feature of TTEView, but has to be programmed).
The Draw method (Listing 2) gets the extent rectangle of the view in QuickDraw
format, and calls FrameRect, and the superclass Draw method. DoMouseCommand
simply sends the SetTarget(this) message to the window enclosing the view, which
means that keystrokes and DoIdle messages will be sent to this text view.
For the scroller enclosing the text boxes, we also derive a new class from
TScroller, TEditView. This allows us to save references to the enclosed TTEBox objects
(two in our case) in instance variables - you never know what you’ll be able to use
them for. The only new method that we define for TEditView is IEditView, which
initializes the print handler and the new instance variables, and sets the window’s
target to the second text box (just for the fun of it).
The application’s class is TEditor. The constructor method of this class
initializes the application and generates a new window containing the views as defined
in a resource file that has been created by ViewEdit. The resource is ‘view’, ID=1002.
This view contains one instance of TEditView, with identifier ‘scrl’, which in turn
contains two instances of TTEBox as subviews, with identifiers ‘tx01’ and ‘tx02’.
Writing code like this where instances of views are generated from templates at
run time requires some attention. If the class is never referenced explicitly in the
source code, either by generating an instance using new, or by calling one of its
methods, the linker will think that class’ code isn’t used and doesn’t need to be included
in the application. Running the application will then generate an error message,
because the code required to initialize the new object can’t be found anywhere. We
therefore have to include dummy references to TEditView and TTEBox, to make sure we
can instantiate the objects at run time. This is done in the code starting with if
(gDeadStripSuppression) {}. Finally, we initialize the newly generated TEditView.
How do we generate the templates for our view in ViewEdit? First of all, we draw
a TScroller of a certain size. We check the box ‘Top view in TWindow’ to indicate that
the view is contained in a window, and then click on the button ‘TWindow
parameters’. This will open a dialog where we can set the window size. It should be 15
pixel bigger than the TScroller in either direction, to accommodate the scroll bars.
Returning to the ViewEdit window, we double-click on the TScroller box, opening the
dialog for the TScroller parameters. Here, we have to set the two size determiners to
‘sizeRelSuperView’, in order to make the scroll bars grow and shrink with the window.
Finally, we find a text box where we can enter the class name. By default, this will be
the name of the standard view that we generated (TScroller in this case). Entering
another name here allows us to generate an object of a class derived from TScroller.
Thus, here we enter TEditView, the name of our derived class. The view identifier, by
default ‘VW01’, can be changed, too; I chose ‘scrl’.
Finally, we draw two TTEView boxes inside our TEditView (drawing them inside
automatically makes them subviews), and change their class names to TTEBox, and the
view identifiers to ‘tx01’ and ‘tx02’. We save the resource file and are ready to go. The
view resource that I just described is contained on the source code disk as ‘editor.rsrc’.
We’re done; building the application will now create a program that displays one
window, scrollable in both directions, in which two text edit boxes are displayed.
Clicking on one of them allows you to enter text there. We’ll continue this example and
see how we can add disk read/write; till then.
Listing 1: editor.h
class TEditor : public TApplication {
public:
pascal TEditor(OSType itsMainFileType);
pascal void HandleFinderRequest();
#ifdef qDebug
virtual pascal void IdentifySoftware();
#endif
};