HFS Grep & Scrollers in Neon

By Jörg Langowski, MacTutor Editorial Board, Grenoble, France

HFS Tiny Grep Utility in NEON 2.0

We'll have a NEON column again after a long pause; just recently I received a beta copy of NEON's version 2.0 (already mentioned in the last column). NEON 2.0 is the long-awaited HFS compatible upgrade, with a lot of changes in the file class definitions and the introduction of a new class, pathlist. With this class, HFS search paths may be defined which are then scanned by the NEON system when files are accessed. Usually, you set up the default search paths in a text file which is kept in the NEON folder and read automatically at startup. If you've set the path names to the appropriate disk and folder names that you are using in your particular development system, the HFS tree search along the path list becomes completely transparent. You may then, for all practical circumstances, regard the collection of folders defined by the search path names as one contiguous MFS volume. With one important difference: pathlist is a subclass of ordered-col, and new search paths may be added to or removed from the list by sending add: or remove:. This can occur during the execution of a program, so you may dynamically change search paths as your application requires.

Applications written in NEON 2.0 can be installed as one single file, putting the kernel and the dictionary together (which were separate in earlier versions). Installed applications have access to the finder information block through another class, Fin. Therefore we may determine how many documents were opened together with the application and whether they are supposed to be opened or printed.

I'm not going to give you all the details on NEON 2.0; quite a number of bugs seem to have been removed, and all in all the system seems to be more stable than the earlier versions. Nevertheless, the version that I saw is a beta test, therefore some bugs can still be expected. Which leads us to this month's example, a string search utility for text files that will work on HFS volumes. It is very much like the NEON 'grep' utility, which only works for MFS, however (even in the 2.0 beta version).

Grep, incidentally, means general regular expression parser, which neither the NEON grep nor our example really are. We are just looking for simple strings in a set of files and cannot use more complicated expressions to define a whole range of strings to look for, such as a 'real' grep can do.

Anyway, a directory-search utility for HFS volumes with added string search in text files makes a good example for using HFS from within NEON, and might also be useful to replace the Grep module on the NEON system disk. Note that the program, given in listings 1 and 2, will not work with earlier versions since it contains some v2.0 specific words.

Even though NEON 2.0 works well with HFS, the HFS - specific traps are not (yet?) directly supported. Therefore we create a simple HFS dispatcher word, HFSd, which takes a parameter block address and a function code off the stack, passes them to the HFS dispatcher in registers A0 and D0, calls the dispatcher trap and puts the result code from D0 back on the stack. The function codes for the HFS-specific calls are given at the beginning of the listing. We use only openWD here, which given a path name in the parameter block, opens the corresponding working directory (folder) and returns a directory ID number in D0.

Scanning a directory for files and folders

There exists a NEON word, getidxfile, which can be used on MFS disks to get information about the i-th file in the directory. It calls the getFInfo trap and places the information in the fFcb parameter block, which in turn can be used to open the file. HFS volumes, however, have to be treated differently. getFInfo still works sometimes on the root level of a volume, and also, by setting the appropriate volume ID, in folders; but it won't find subdirectories and, worst of all, sometimes crashes (at least according to some experiments I did both in NEON and Mach2). The correct way to scan an HFS directory is to call the getCatInfo routine, which will return the i-th directory entry and also indicate whether it is a file or another folder. This is implemented in the getixHFSfile word (listing 1).

Scanning through all of the disk now becomes very simple: we start with the root directory, and as soon as we find an entry that is another directory, we call the scanning routine recursively and repeat the process (remembering the old directory ID and file index on the stack). Scanning will be finished when no more entries are found in a directory; then the recursion will back up one level, until one is back at the root level and finished with all of the disk.

The DIR routine implements this strategy of descending the directory tree. It makes use of another definition, $openWD, which expects a string address as an input parameter, opens that particular folder and returns the directory ID (or an error code) on the stack. Successive calls to nextFile will return file or folder names further and further down the list of the working directory; if a folder is found, it is opened and a DIR done on its contents. Note that words may be called recursively in NEON, since no smudge bit is set during a definition. If you wanted to rewrite DIR in Mach2, you would have to indicate explicitly that this is to be a recursive definition (besides doing all the other necessary changes...).

grepDIR, then, is our text file string searcher. It works exactly the same way as DIR, except that after a text file has been found, it is opened and scanned for the search string. All files except text files are ignored. The string search routine is part of the NEON source code, therefore we won't print it here. Simply take the grep source file, copy the searchfile definition out of it and paste it into the example text. I have not written the program as a NEON module, but this can easily be done and you can rebuild your system with the new grep utility. Included is a word grepOne which will scan a single file, and menu definitions to change disk drives and turn the printer on and off.

Control handling in NEON - an alternate way

NEON usually takes charge of tracking controls in a CtlWind automatically. As one of our readers, Phil Barnard, remarked in a letter (part of which I already quoted in my last column), this automatic tracking of controls sometimes can lead to a stack-heap collision (system error 28). NEONs default stack setting, 3000, seems somewhat low anyway, since one does get ID=28 bombs out of the blue even in other situations, such as when one changes repeatedly from the NEON window to a desk accessory like MockTerminal and back. Those situations can be avoided by re-installing the NEON kernel with a larger stack; I generally use 32K without any problems.

The second program example, listing 3 (by Phil Barnard), gives an explicit implementation of a vertical scroll bar class. It creates an example window on which this scroll bar is used. I quote from his letter:

" The existing vertical scroll bar class appears to have problems (even the demo scrolling bombs if not handled right), which seems to be caused by overflow of the return and methods stack during the repeated execution of the 'Pascal' procedure passed as a parameter to the TrackControl toolbox call. Am I right?

This may be avoided by passing (-1) instead and only using the TrackControl call to track the thumb as in the following demo (...). To run the demo, load it and type the word 'TEST'. After the demo, click in fWind and type 'FIX'. "

After my tests, this seems to be one other way to avoid stack crashing problems; it works with smaller stack sizes than the standard NEON controls. As a general remark, if you see strange things happening with some of the predefined words of any of the existing Forth or Forth-related systems, just try and redefine the offending part yourself. This is very easy in Forth since often the source code for large parts of the system is provided or can be easily decompiled.

Fig. 1: Example of the WinTool Inside Macintosh data base

WinTool - Inside Macintosh on line database

We have quite an active scene of Macintosh developers here in Grenoble. As an example of what is being thought up on the other side of the Atlantic, I'd like to present to with a very nice utility that I was able to preview recently and that I'm already heavily using. In fact, it opens up considerable space on my crammed desk, because I can leave the three volumes of IM on the shelves most of the time now.

The program is called WinTool; it is a small data base implemented as a desk accessory. Although at present meant to provide you with an instant means of getting IM information, it could be used as a general data base by setting it up appropriately.

Here's how it works: You install a desk accessory (quite a hefty one, takes 44K) which is used to access indexed data bases that you keep somewhere on your development disk. The copy that I looked at contained a Managers and a Toolbox database. (Those bases, by the way, also take up quite a bit of space, all in all, installing Wintools will add 300 K to your system.) When you call up a desk accessory, it'll add a new menu, from which you may select options such as opening and closing bases, or (most important) finding entries. See figure 1.

So you don't remember the parameters to pass to ModalDialog? Just select the appropriate entry, and the correct procedure call - with trap number and IM page reference - will come up almost instantly. Even on my two-floppy system. Much faster than browsing through Inside Macintosh. This is particularly useful (for Forth users) if you want to add a new glue routine to a trap that has not been provided in your standard system, want to know the exact location of a system global, the structure of a particular record, etc. etc. The managers database gives you some sort of an 'overview' of definitions contained in the individual sections of IM; the Toolbox database then gives the details of the definition. Words may be selected in a file that you're currently working on and then found in the data base with the menu option 'find selection'. You can also add to the existing entries as your disk space permits, e.g. if you've found some particular quirks about how a certain routine works, about bugs and so on. I'm going to create my own index for Forth words, because I can never remember all of them (working with too many different Forth systems).

PS: As you read this, WinTool might be obtainable through MacTutor mail order. [Watch for it in an up-coming issue.-Ed]

One last remark for our French readers

Since we seem to have quite a large readership in Europe and especially in France by now, I think it is appropriate to make one short remark about connecting a modem to the Macintosh in France. [Other readers may now skip to the next article.]

The Macintosh may be very easily connected to a standard Minitel by a three-wire connection. [For other readers, who are still with me: the Minitel is a videotext terminal containing a 1200 baud modem that the French postal service provides free of charge for you. Of course, they charge you to use it.]

The way to set up the connection is as follows: Get a 3-pin DIN plug that plugs into the interface socket of the Minitel. Make the following connections:

DIN plug Macintosh DB-9 Mac Plus mini-DIN

1 (TTL input) 4 (TxD+) 6 (TxD+)

2 (ground) 3 (ground) 4 (ground)

3 (TTL output) 8 (RxD+) 8 (RxD+)

and off you go. (Try using one of the standard terminal programs on it).

Last minute news: I just received a newsletter from Palo Alto Shipping that there is a new Mach2 upgrade on its way which contains an integrated debugger (finally reinstalled), integrated editor, automatic resource integration into turnkey applications, and more nice things. I'll keep you informed on it.

Listing 1:  Tiny Grep and Directory Descent utility
\ © J. Langowski / MacTutor, 1986
\ written in NEON v. 2.0

DECIMAL
-35  CONSTANT  nsvErr( no such volume error ) 
-43  CONSTANT  fnfErr( file not found error )

HEX
3F6  CONSTANT  FSFCBLen \ >0 if HFS is being used
-1   CONSTANT  MFS \ -1 if MFS is running 
( this global variable is given for your information. )
( It is automatically checked by the NEON 2.0 word hfs? )

10   CONSTANT  Dir/File \ bit 4 determines whether it is
   \ a file or directory
   
DECIMAL

\ Routine selectors for HFS traps 
1   CONSTANT  OpenWD 
2   CONSTANT  CloseWD
5   CONSTANT  CatMove
6   CONSTANT  DirCreate
7   CONSTANT  GetWDInfo
8   CONSTANT  GetFCBInfo
9   CONSTANT  GetCatInfo
10  CONSTANT  SetCatInfo
11  CONSTANT  SetVolInfo
16  CONSTANT  LockRng
17  CONSTANT  UnlockRng

\ some more constants
80  CONSTANT  FileParamSize 
106 CONSTANT  CatParamSize

\ offsets into parameter block
12  CONSTANT  ioCompletion ( completion routine [long word] )
16  CONSTANT  ioResult  ( result code returned here [word] )
18  CONSTANT  ioNamePtr \ holds pointer to file name string
   \ or pathname string [long word] 
22  CONSTANT  ioVRefNum 
24  CONSTANT  FioFRefNum  ( path reference number [word] )
26  CONSTANT  FioFVersNum ( usually zero [byte] )
28  CONSTANT  FioFDirIndex( index [word] )
30  CONSTANT  FioFlAttrib ( file attributes byte [byte] )
31  CONSTANT  FioFlVersNum ( version number [byte] )
32  CONSTANT  FioFlFndrInfo 
48  CONSTANT  FioDirID  
48  CONSTANT  FioFlNum  

0 value Index    
0 value VolRefNum
0 value DirID    

: ?dup dup if dup then ;

\ the HFS dispatcher...
create hfsD
 popD0
 popA0
 $ A060 w,
 pushD0
 next,

: $openWD { name -- VRefNum / errcode 0 }
 0 fFcb ioCompletion + !
    name +base fFcb ioNamePtr + !
 0 fFcb FioFDirIndex + w!
 fFcb +base OpenWD hfsD extend
 ?dup if 0 else fFcb ioVRefNum + w@ then;

: getixHFSfile { indx \ ResCode --  errorResCode }
   \ setup parameter block: 
    VolRefNum fFcb ioVRefNum + W!  \ specify the volume 
    DirID fFcb FioDirID + ! \ pass directory id 
    pad +base fFcb ioNamePtr + !   \ expect file name here 
    indx fFcb FioFDirIndex + W!  \ pass current index
    hfs? IF fFcb +base GetCatInfo hfsD extend -> ResCode 
       ELSE fFcb fcall PBGetFInfo extend -> ResCode
       THEN
    ResCode   \ pass ResCode on stack;

: NextFile  1 ++> index   index getixHFSFile ;   
    
0 value level

: indent cr level 4 * spaces ;  ( for pretty printing )

: DIR { vol  \  resCode  --   } 
    0 -> Index   ( initialize index )
    vol -> VolRefNum ( choose volume in internal drive )
    2 -> DirID ( specify root directory,  significant in HFS )
    BEGIN 
 NextFile -> resCode
 ResCode 0= 
      IF 
   indent
   fFcb FioFlAttrib + C@  ( get the attributes byte )
   Dir/File AND  ( file or directory ? )
   IF indent
 33 tface ." Directory -> " pad count type
 0 tface
 1 ++> level
 index volrefnum ( push on stack )
   pad $openwd DIR ( recursive call to DIR )
 -> volrefnum  -> index  ( pop off stack )
 -1 ++> level
 indent
   ELSE pad count type
   THEN
      THEN
    ResCode 
    UNTIL ( error found )
    
    ResCode ( which error ? )
    CASE
      fnfErrOF
 level ?dup 
 IF    cr 1- 4 * spaces 
  33 tface ." End of directory" 0 tface 
 ELSE cr 33 tface ." End of contents listing" 
 0 tface  quit
 THEN
 ENDOF
 nsvErr OF  cr ." There is no disk in drive number " vol . ENDOF
 cr ." Error #" ResCode .
    ENDCASE
;  
  
String gpattern
String linBuf
String target

0 value #lines \ total lines searched

\ SEARCHFILE - This routine searches a file for the presence of 
\ gpattern, outputting all lines that contain the string.
\ It is contained in the 'grep' source file on the NEON 2.0 disk.
\ Please insert the appropriate source code here....
\  ...
\  ...
\  ...

: grepInit
 0 -> #lines
 indent ." Searching for: " print: gPattern CR
 uc: gPattern 2drop
 new: linBuf
;

: grepDIR { vol addr len \  resCode gcurs --   } 
 new: loadFile new: gpattern new: target 
 addr len str255 -base count put: gPattern
 curs -> gcurs -curs \ Preserve cursor status
    grepInit
 0 -> Index \ initialize index  
    vol -> VolRefNum \ choose volume in internal drive  
    2 -> DirID  \ specify root directory , immaterial for MFS

    BEGIN ?pause
 NextFile -> resCode
 ResCode 0= 
      IF 
   indent
   fFcb FioFlAttrib + C@  \ get the attributes byte  
   Dir/File AND  \ file or directory?  
   IF indent
 33 tface ." Directory -> " pad count type
 0 tface
 1 ++> level
 index volrefnum \ push on stack  
   pad $openwd addr len grepDIR 
 \ recursive call to grepDIR 
 -> volrefnum  -> index    \ pop off stack 
 -1 ++> level
 indent
   ELSE pad count type
 pad count name: topFile
 volrefnum setVref: topfile
 openReadOnly: topFile ?error 132
 GetFileInfo: topFile  drop
 GetType: topFile txType = 
 IF searchfile THEN
 close: topFile drop
   THEN
      THEN
    ResCode \ go until error found 
    UNTIL
    
    ResCode 
    CASE
      fnfErrOF
 level ?dup 
 IF    cr 1- 4 * spaces
  33 tface ." End of directory" 0 tface 
 ELSE cr 33 tface ." End of contents listing" 
 0 tface gcurs -> curs remove: loadfile quit
 THEN
 ENDOF
 nsvErr OF  
 cr ." There is no disk in drive number " vol . ENDOF
 cr ." Error #" ResCode .
    ENDCASE
    remove: loadfile
;

0 value drive

: grepone
 new: loadFile
 txtype 1 stdget: topfile
 IF
 " Enter search string:" doInDlg
 IF new: gpattern new: target 
 str255 -base count put: gPattern
 cls grepinit
 openreadonly: topfile ?error 132
 searchfile
 remove: loadFile
 THEN
 THEN
;

: grepd 0 -> level
 drive " Enter search string:" 
 doInDlg if cls grepdir else drop then
;

1 menu filemenu
3 menu editmenu
7 menu grepmenu

: drive1 1 -> drive 5 uncheck: grepmenu 4 check: grepmenu ;
: drive2 2 -> drive 4 uncheck: grepmenu 5 check: grepmenu ;
: pron  +print 7 uncheck: grepmenu 6 check: grepmenu ;
: proff -print 6 uncheck: grepmenu 7 check: grepmenu ;

: init 
 " grepmenu.txt" getmtxt 
 drive1 proff
;
Listing 2: 'grepmenu.txt' Menu Text file for Listing 1
APPLEMEN  1
  "$14" 
    "About Neon™..." about
    "(___________"  null
    "RES"  DRVR   \  get desk accy names
    "\\\"  
fileMENU  256
  "File"
     "Quit"   bye
     "\\\"
editMENU 261
  "Edit"
     "(Cut/X" null
     "(Copy/C" null
     "(Paste/V" null
     "\\\"
grepMENU 262
  "Grep"
    "Grep one" grepone
    "(___________"  null
    "Grep all" grepd
    "Drive 1" drive1
    "Drive 2" drive2
 "Printer on" pron
 "Printer off" proff
    "\\\"
xxx

Listing 3: Example for directly accessed scroll bars in NEON
\ by Phil Barnard, Launceston, Tasmania, Australia.
\
\ actFW added since it is no longer contained in NEON 2.0
\ (J. Langowski)
: actFW enable: menubar 
 4 1 do i enable: filemen loop 
 decimal initFont
;

0 value part#

:CLASS vsBar <super object

 rect vsRect
 var wPtr
 Handle ctlHndl

\ initializes the scrollbar rectangle from the port rectangle
:M PUTRECT:  ( wPtr -- )
 put: wPtr
 getRect: [ get: wPtr ]
 2swap swap drop
 3 pick 16 -
 swap 2swap
 put: vsRect
;M

\ instantiates vertical scrollbar in window, returning handle in ctlHndl
:M NEW:  ( -- )
 0 \ room for ctlHandle returned 
 get: wPtr +base \ window pointer
 abs: vsRect\ scrollbar bounds rectangle
 nullOSstr\ null Str255
 256 makeint\ visible
 0 makeint\ value
 0 makeint\ min
 0 makeint\ max
 16 makeint \ procID for scrollbars
 0 \ refCon
 call NewControl
 put: ctlHndl
;M

\ disposes of heap storage for the scrollbars
:M KILL: ( -- ) get: ctlHndl  call DisposControl  ;M


\ draws scrollbars on update events
:M DRAW: ( -- ) get: wPtr  +base call DrawControls  ;M

\ hilites the given part number
:M HILITE: { thePart -- } 
 get: ctlHndl thePart makeint call HiliteControl ;M
:M PUTMIN:  ( min -- ) 
 get: ctlHndl swap makeint call SetMinCtl  ;M
:M GETMIN:  ( -- min ) 
 word0  get: ctlHndl call GetMinCtl I->L ;M
 :M PUTMAX:  ( max -- ) 
 get: ctlHndl swap makeint call SetMaxCtl  ;M
:M GETMAX:  ( -- max ) 
 word0  get: ctlHndl call GetMaxCtl I->L ;M
 :M PUTVAL:  ( val -- ) 
 get: ctlHndl swap makeint call SetCtlVal  ;M
:M GETVAL:  ( -- val ) 
 word0  get: ctlHndl call GetCtlVal I->L ;M

\ tests to see which part got hit and returns 0 or partcode in part#
:M TEST: ( -- ) 
 word0  get: ctlHndl  where: fevent  G->L
 call TestControl  I->L  -> part# 
;M
 
\ tracks the mouse, executing part handler's default procedure while 
mousedown
:M TRACK:  ( -- partNumber or 0 on mouse-up )
 word0  \ space for INT result
 get: ctlHndl
 where: fevent G->L\ mouse point in local coordinates
 -1
 call TrackControl
 I->L
;M

;CLASS

window  edWind
vsBar edBar

\ close activate draw content handlers
: fix <[ 4 ]> 'cfas null actFW cr null actions: fwind
 close: edWind cls ;

: ok? depth . depth 0 > if . then rdepth . mdepth . ;

\ define scrollbar handlers
: showValue 100 50 gotoxy getVal: edBar . ;
: PUp  getVal: edBar 5 - putVal: edBar showValue ;
: PDn  getVal: edBar 5 + putVal: edBar showValue ;
: LUp  getVal: edBar 1 - putVal: edBar showValue ;
: LDn  getVal: edBar 1 + putVal: edBar showValue ;
: doThumb track: edBar drop showValue ;

: doPart ( part# -- )
 case 20 of LUp endof
 21 of LDn endof
 22 of PUp endof
 23 of PDn endof
 129 of doThumb endof
 drop
 endcase
;

: makeEdfalse setDrag: EdWind
 false setGrow: EdWind
 2 241 510 340 put: tempRect
 tempRect " ed" 0 true false new: EdWind;

: drawAll draw: EdBar ;

: contEd
 test: EdBar
 part#
 if part# hilite: edBar
 begin stilldown? while
 part# doPart
 repeat
   0 hilite: edBar
 then;

: actF  become actFW cls ;

: actEd begin
 next: fevent
 if 2drop then
 again;
\ close activate draw content
\ instantiate both windows & bar  and display bar
: test makeEd
 set: EdWind-curs
 addr: edWind  putRect: edBar 
 \ setup vsRect from owning window
 new: edBar
 0 putMin: edBar 100 putMax: edBar
 0 putVal: edBar draw: edBar
 <[ 4 ]> 'cfas null actEd drawAll contEd actions: edWind
 <[ 4 ]> 'cfas null actF null null actions: fWind ;