ADVERTISEMENT

Related Info: File Manager Event Manager

FKEYs in THINK Pascal, Easy

Have you ever had to restart because a file was left open? No more! Read on.

By Roy Lovejoy, Sunnyvale, California

About the author

Roy Lovejoy is a Software Engineer at Calera Recognition Systems. He was previously working at Claris Corporation as one of the MacWrite II engineers. This is his first article for MacTutor. What do you think?

A Bit of History

When the Macintosh arrived on the scene in February of 1984, the world knew it was unique; its profile, screen, and keyboard were all different from the then-standard IBM PC. One of the attributes that IBM-ers scoffed at was the lack of "Function keys". You know function keys, those funky little buttons that do an infinitely many different things (depending on which program you are running). Well, we have news for the scoffers. The Macintosh has had function keys, or FKEY’s as they are called, since its inception.

The FKEY’s that were included were ones to eject the internal and external floppy disk, take a snapshot of the screen and save it to a MacPaint file, and print the screen, or the front window. These FKEY’s were assigned numbers 1 , 2, 3, and 4 respectively and were triggered by the Command key followed by the associated digit. Since the introduction of different size and depth screens, and printers, they of course had to be modified. Many people have written other useful FKEY's, and some have become very well known (i.e., switch-a-roo).

FKEY's are a pretty safe bet. Since they are trapped during a GetNextEvent or WaitNextEvent, they are available in a large percentage of applications. Since Desk Accessories are going the way of the brontosaurus, or so they say, FKEY’s are (hopefully) a safe utility feature in the future.

General

Now these function keys are in no way difficult to code. They are just simply different to code. I have found that if I need a utility, an FKEY is always my first choice, then comes a Desk Accessory, then an Application. (You don’t have all of the DRVR problems that are inherent in a desk accessory.) Basically an FKEY is a procedure that has no true globals (true globals are ones that are referenced off of the 68000 register A5) and is compiled to an 'FKEY' resource. There are many safe, and many sneaky ways to have a 'global' area, but that will be good subject matter for a future article.

An FKEY can be completely Modal - it might simply bring up a Dialog and let you set/reset a value, or it can have a robust user interface, complete with menus and windows. This article will describe the former.

In THINK Pascal, an FKEY is simply a unit that is compiled into a resource, of type FKEY. See figure for Project Setup. The unit must have the entry procedure be called ‘main’ and have no parameters. There must not be a ‘program’. See Figure 1.

Figure 1: Set Project Dialog (set for FKEY #5)

Why did I write this?

As an applications programmer I have many times (read > 300) written file I/O routines that save and retrieve program’s data structures. Naturally, in the course of human events, errors happen, sunspots appear, neutrinos expire, all after you open a data file, but before you get a chance to close it properly. This problem leads to a file, on your storage device, that is marked busy. This file can not be closed by your program (your variables have since committed electronic suicide, and your FileRefNum has gone with them), and you can not throw the file out, (because the busy bit is set). So, what do you do? Well, the busy bit is reset when the volume gets dismounted. That is acceptable for a floppy disk, but if it is your currently-booted hard disk, that poses a problem. What I wanted to do was an FSClose on the file, regardless of how it got opened. I was very frustrated, logged countless hours on networks looking for a utility to ease my woes. Finally I said, forget it, I’ll do it myself. Here it is.

What does it do?

Basically, when you (or any application) do an FSOpen or equivalent, memory is allocated for the file’s information. This FKEY simply tries to open the file; if the file is already open, it makes a parameter block call to get the file reference number, then uses that to close the file. If the file was not open originally, it is now because of the FSOpen, and so the FKEY goes ahead and closes it. A diagnostic dialog makes everything friendly.

A Bit of Style

The final resting place of an FKEY is either the System File or an exterior resource opened by a Suitcase-like program. This does not mean you can’t debug it elegantly. Oh, sure. “It’s a code resource. Those are hard to debug!!” I have some Arizona beach front property for you, too. What I do is have two Think projects. One has the standard Runtime.Lib and an extra file that is just a program stub that calls ‘Main’. I can then go on and debug in the glorious THINK environment. The other project has the DRVRruntime.lib and no ‘program’ file. This one has debugging turned off and the project type set to code resource. See Figures 2 and 3.

Figure 2: Project Set Up for debugging

Figure 3: Project Set Up for compiling

Listing

{======================}
unit FKEY;
{======================}
interface
{======================}
 procedure Main;
{======================}
implementation
{======================}
 procedure Main;
 var
 dlgOrigin: Point; {Top-left corner of dialog box}
 theReply: SFReply;{Data returned by SFGet dialog}
 theFile: INTEGER; {Reference number of file}
 resultCode: OSErr;{I/O error code}
 TypeList: SFTypeList;  {Type List to search for }
 Block: ParamBlockRec;  {Used to get file ref number}
 WIND: WindowPtr;{Display Window }
 bounds: Rect; {window rectangle Rectangle }
 OldPort: GrafPtr; {Graf Port set upon entry}
 dummy: LONGINT; {parameter of Delay}
{======================}
{ CenterDraw}
{ Input: String to Draw , line number to draw on.}
{ (String is centered horizontally on the window.)}
{======================}
 procedure CenterDraw (s: Str255; y: INTEGER);
 var
 x: INTEGER;
 begin
 with WIND^.portRect do
 begin
 x := (right + left) div 2 - StringWidth(s) div 2;
 MoveTo(x, y * 16);
 end;
 DrawString(s);
 end;
{======================}
 begin
 GetPort(OldPort);
 SetRect(bounds, 85, 40, 420, 100);
 WIND := NewWindow(nil, bounds, '', TRUE, dBoxProc, pointer(-1), FALSE, 
0);
 SetPort(WIND);
 TextFace([underline]);
 CenterDraw('Close File FKEY', 1);
 TextFace([]);
 CenterDraw('Select the file you wish to close.', 2);

 SetPt(dlgOrigin, 85, 120);         {Set up dialog origin}
 SFGetFile(dlgOrigin, '', nil, -1, TypeList, nil, TheReply);

 with TheReply do
 if good then
 begin
{Try to open file}
 resultCode := FSOpen(fname, vRefNum, theFile);
{if it was already open, get the file ref number}
 if resultCode = opWrErr then
 with Block do
 begin
 ioNamePtr := @fName;
 ioVRefNum := vRefNum;
 ioFDirIndex := -1;
 resultCode := PBGetFInfo(@Block, false);  {Get Finder info}
 theFile := ioFRefNum;
 CenterDraw(Concat('“', fName, '” is now closed.'), 3);
 end
 else
 CenterDraw(Concat('“', fName, '” was not open.'), 3);
{Do the actual closing... regardless if it was open before the FKEY or 
not}
 ResultCode := fsClose(theFile);
 end;
 Delay(45, dummy);{Wait a while 3/4 of second}

 DisposeWindow(WIND); {Close up}
 SetPort(OldPort);
 end;
{======================}
end.
{======================}

program Test;
 uses
 FKEY;
begin
 Main;
end.