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 <rfl@ODDJOB.UCHICAGO.EDU>

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

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,

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
};

class TEditView : public TScroller {
public:
 TTEView*fTEView1;
 TTEView*fTEView2;
 pascal void IEditView(TWindow *itsWindow);
};

class TTEBox : public TTEView {
public:
 pascal void Draw(Rect *area);
 pascal struct TCommand 
 *DoMouseCommand(Point *theMouse,
 EventInfo *info, Point *hysteresis);
};

Listing 2: editor.cp

#include <UMacApp.h>
#include <UPrinting.h>
#include <UTEView.h>
#include <Fonts.h>
#include <ToolUtils.h>

#include “editor.h”

const OSType kSignature   = ‘JLMT’;
const OSType kFileType    = ‘JL01’;
const int kWindowID= 1002;

pascal TEditor::TEditor(OSType itsMainFileType)
{
 TWindow*aWindow;
 TEditView*aEditView;
 TTEBox *aTEBox;
 
 IApplication(itsMainFileType);

 aWindow = NewTemplateWindow(kWindowID,nil);
 FailNIL(aWindow);
 
 if (gDeadStripSuppression)
 {
 aEditView = new TEditView;
 aTEBox = new TTEBox;
 }

 aEditView = 
 (TEditView*) aWindow->FindSubView(‘scrl’);
 FailNIL(aEditView);
 aEditView->IEditView(aWindow);
 
 aWindow->Open();
}

pascal void TEditor::HandleFinderRequest()  {};

#ifdef qDebug
pascal void TEditor::IdentifySoftware()
{
 ProgramReport
 (“\pEditor ©J.Langowski/MacTutor May 1991”,false);
 inherited::IdentifySoftware();
}
#endif

pascal void TEditView::IEditView(TWindow *itsWindow)
{
 TStdPrintHandler*aStdPrintHandler;
 
 aStdPrintHandler = new TStdPrintHandler;
 FailNIL(aStdPrintHandler);
 aStdPrintHandler->IStdPrintHandler
 (nil,this,kSquareDots,kFixedSize,!kFixedSize);
 fPrintHandler = aStdPrintHandler;

 fTEView1 = 
 (TTEView*) itsWindow->FindSubView(‘tx01’);
 FailNIL(fTEView1);
 fTEView2 = 
 (TTEView*) itsWindow->FindSubView(‘tx02’);
 FailNIL(fTEView2);
 
 itsWindow->SetTarget(fTEView2);
}

pascal void TTEBox::Draw(Rect *area)
{
 Rect itsQDExtent;
 
 PenNormal();
 GetQDExtent(&itsQDExtent);
 FrameRect(&itsQDExtent);
 inherited::Draw(area);
}

pascal struct TCommand 
 *TTEBox::DoMouseCommand(Point *theMouse,
 EventInfo *info, Point *hysteresis)
{
 if (Focus())
   {  GetWindow()->SetTarget(this); }

 return inherited::DoMouseCommand
 (theMouse,info,hysteresis);
}

TEditor *gEditor;

int main()
{
 InitToolBox();
 if (ValidateConfiguration(&gConfiguration))
 {
 InitUMacApp(8);
 InitUPrinting();
 InitUTEView();
 gEditor = new TEditor(kFileType);
 FailNIL(gEditor);
 gEditor->Run();
 }
 else StdAlert(phUnsupportedConfiguration);
 return 0;
}

Listing 3: editor.r

/* editor.r 
 Rez file for MacTutor C++/MacApp Editor example
 J. Langowski May 1991
*/

#ifndef __TYPES.R__
#include “Types.r”
#endif

#ifndef __SYSTYPES.R__
#include “SysTypes.r”
#endif

#ifndef __MacAppTypes__
#include “MacAppTypes.r”
#endif

#ifndef __ViewTypes__
#include “ViewTypes.r”
#endif

#if qDebug
include “Debug.rsrc”;
#endif

include “MacApp.rsrc”;
include “Printing.rsrc”;

include “Defaults.rsrc” ‘SIZE’(-1);
include “Defaults.rsrc” ‘ALRT’(phAboutApp);
include “Defaults.rsrc” ‘DITL’(phAboutApp);
include “Defaults.rsrc” ‘cmnu’(mApple);
include “Defaults.rsrc” ‘cmnu’(mEdit);
include “Defaults.rsrc” ‘cmnu’(mBuzzWords);

include “Editor” ‘CODE’;

include “editor.rsrc”;

#define kSignature ‘JLMT’
#define kDocFileType ‘JL01’
#define getInfoString“©1991 J.Langowski/MacTutor. “

/* ------------------------------------------------------------------------*/

resource ‘cmnu’ (2) {
 2,
 textMenuProc,
 allEnabled,
 enabled,
 “File”,
  {
 “Close”, noIcon, noKey, noMark, plain, 31;
 “-”, noIcon, noKey, noMark, plain, nocommand;
 “Page Setup ”, 
 noIcon, noKey, noMark, plain, 176;
 “Print One”, noIcon, “P”, noMark, plain, 177;
 “Print ”, noIcon, noKey, noMark, plain, 178;
 “-”, noIcon, noKey, noMark, plain, nocommand;
 “Quit”, noIcon, “Q”, noMark, plain, 36
 }
};


resource ‘MBAR’ (kMBarDisplayed,purgeable) 
{
 {mApple; 2; mEdit;}
};


/*--------------------------------------------------------------------------
 The overall package version
----------------------------------------------------------------------------*/
RESOURCE ‘vers’ (2,
#if qNames
“Package Version”,
#endif
 purgeable) {
 0x02,
 0x00,
 beta,
 0x06,
 verUs,
 “2.0”,
 “MacApp® 2.0, ©Apple Computer, Inc. 1990”
};


/*--------------------------------------------------------------------------
 The revision of this particular file
--------------------------------------------------------------------------*/
RESOURCE ‘vers’ (1,
#if qNames
“File Version”,
#endif
 purgeable) {
 0x01,
 0x00,
 beta,
 0x05,
 verUs,
 “Editor”,
 “v 0.9, ©JL/MacTutor 1991”
};

/* =========== debug window ============ */
resource ‘dbug’ (kDebugParamsID,
#if qNames
“Debug”,
#endif
 purgeable) {
 {350, 4, 474, 636}, /* Bounding rect for debug window */
 1,   /* Debug window font rsrc ID (normal = monaco) */
 9,/* Debug window font size (normal = 9) */
 100, /* Number of lines */
 100, /* Width of lines in characters */
 true,  /* open initially */
 “Jörg’s Debug Window”  /* Window title */
};