Easy FKEY
Volume Number: 8
Issue Number: 2
Column Tag: Pascal Workshop
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
Note: Source code files accompanying article are located on MacTech CD-ROM orsource code disks.
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.
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.
