IAC Driver Demo
Volume Number: 4
Issue Number: 11
Column Tag: Advanced Mac'ing
IAC Driver Demo in MPW C 
By Frank Alviani, Contributing Editor, Waukegan, IL
The Great IAC Sample Editor!!
(or a reasonable facsimile thereof...)
Frank Alviani
I had just crawled out of my sickbed and back to work. After getting the IAC
Driver article to Dave Smith at MacTutor in the nick of time (as usual), wrestling
with thousands of lines of Pascal was starting to look like a little rest - when who calls
but our beloved assistant editor, Kirk.
“How’s the next article coming, Frank? Gonna have it ready in time - maybe
even a little early (wistful sigh)?” “No problem, Kirk”, I assured him; I had already
set aside the evening of the deadline to get it written. I would have preferred to be out
dancing with Shellie and Alice like Paul, but an editor’s gotta do what an editor’s gotta
do....
Before continuing with the actual meat of this article, please understand that I
assume you have read (and hopefully understood) the previous IAC articles (in the
August and October ’88 issues of MacTutor). If you haven’t, I’m afraid this is going to
be quite incomprehensible...
The IAC Sample Editor was written to demonstrate how to implement most
(though not all) of the capabilities provided by the SAWS IAC driver. I chose to use a
text editor for the same reasons many others have chosen to write sample text editors
- TextEdit handles the surprisingly groaty details of handling the characters, allowing
me to concentrate on the other aspects of the application. It handles a few small
“frills”, such as choosing fonts and text sizes, because those are almost free; more
complex enhancements such as scrolling have been left as “an exercise for the
student”. THE CRITICAL MATERIAL IS THE IAC HANDLING, NOT THE TEXT HANDLING.
[Window updating of the displayed text could use some work, but since we have
published fully functional text editors in the past, the reader is referred to those
articles for improvements to the text editing portion of the program. For purposes of
this article, the ability to link documents betweeen two of these editors running
together is what is important. A change in the linked text in one document, causes the
linked text in another document to change automatically, thus creating integrated
application software between two independent applications! -Ed]
Like most software, this sample editor is not 100% perfectly debugged (my
employer has this delusion that I should be producing code for him during the day
rather than debugging software for MacTutor), but all the important pieces are
reasonably functional. The functions that are known to have holes are:
1) Auto-linking between two previously linked documents is somewhat unreliable.
Alternative methods of accomplishing this are discussed.
2) Identification of source and target extents in the “Links” menu is occasionally
reversed.
Changes To The IAC Driver
During the course of debugging this sample editor, the “Complete Dependency”
routine was found to be excessively complex and slightly buggy. After revision [found
on this month’s source code disk, -Ed], the rules it follows for handling slot-IDs are
much simpler:
1) Until a document registers as a data source, its slot is filled with a “dummy”
value of 1 to hold its place and indicate “target only” status (it doesn’t have a
document ID yet).
2) When a target document does register as a data source, its slot is refilled with its
assigned document ID.
In practice, this change would have very little effect on writing an application.
The only real difference is that it is always a good idea to start a session with a slot-ID
of 0 and let the IAC driver assign a slot, rather than trying to re-register under a
slot-ID from the previous session.
Basic Additional IAC Necessities
The fundamental additional task facing an application using the IAC driver is that
of keeping track of its data extents. You, as the source of data to other programs, must
monitor each source of data in your document(s) and write any changed extents to the
driver for the use of your client applications.
A change in a data extent can involve 2 factors: the contents of the extent, and its
“size”. Monitoring changes can vary widely in complexity, where most of the
complexity involves monitoring the “size” of the data extents. For example, in an
object-oriented graphics program such as MacDraw, the “size” of a data-extent (a
graphic object) is unlikely to change under most circumstances, and so involves
rather little effort to maintain normally. On the other hand, almost any operation in a
text-processor is likely to change the size of an extent, and therefore involves quite a
bit of effort to keep up-to-date.
Since most programs are at least as interested in using data as in generating it,
you are likely to also be a client (or dependent) of one or more other programs. In this
case, it is your responsibility to check with the driver periodically to see if any data
sources you depend on have changed, and to down load the data if they have. You need to
maintain the link “ targets” so that they can be updated as new information becomes
available.
Let’s spend a few moments looking at how some basic tasks are done:
Checking for Updates - A client program is expected to periodically poll the IAC
driver to determine if any of its source extents have been updated. Being a periodic
action, this naturally fits into the main event loop. I recommend doing it during
null-event processing, since you aren’t interfering with other activity. A possible
concern with this approach is that of loading down the system by continuously polling
the driver, and slowing down the normal response time; in the sample editor, this
polling is done only at 1 second intervals. The only negative to this is that there can be
up to 1 second before client applications respond to an update.
Determining when to update the IAC driver - this is the server’s side of the
cooperation required. In the sample editor, I decided that the user would find the time
needed to update the driver between keystrokes interfering with its usability, so the
driver is updated only when you leave an extent [Note: in this version, only clicks
outside an extent are checked - an extension for the future would be to also check the
arrow keys.] In some applications (such as a real-time mail system) 1
update/keystroke might be exactly what is needed.
The ideal to strive for is to update the shared data as often as possible without
sending meaningless intermediate data and without spending excessive time during the
update process. Transmitting each digit to a spreadsheet as it is typed, for example,
would be undesirable since recalculation might very well be triggered for each
keystroke, rather than at the end when the entire number is sent.
Maintaining Extents - The simplest approach seems to do this on the fly. As
mentioned above, changes to either the contents or the “size” of an extent need to be
recorded. The sample editor in fact simply assumes that if you are leaving a source
extent then you were probably doing something in it, and updates the driver. A more
sophisticated approach would be to maintain a “dirty” flag for each extent, and update
the IAC driver only if it was true.
Any operation that can affect the “size” of an extent determines the amount of
change and adjusts the extent accordingly.
Providing a User Interface - In keeping with the visual nature of the Macintosh,
there should be a visual method of making and displaying links between documents, that
is consistent with the user interface guidelines Apple has developed. Simply typing in a
starting and ending character position in a text editor, for example, is utterly
unacceptable. The “magic clipboard” metaphor - a clipboard between applications that
updates itself without intervention from the user - provides a logical extension that
can be further developed.
User Interface Implementation
Most of the user-interface aspects of the IAC were implemented using menu
commands. I chose this approach because it is familiar to all Mac users and independent
of the application type.
All commands for starting and completing dependencies were placed on the Edit
menu, since I am using the “magic clipboard” metaphor to make inter- application
communications seem more familiar to the user. The “kill link” command is on the
Edit menu simply because it is the location most of us would expect.
The method for displaying the location of IAC links is modeled after that of MPW:
a menu with 1 menu item for each link in the document. The menu is not created until
the first link exists. This approach was taken for several reasons. The most important
implementation reason was that the ROM TextEdit package doesn’t support
discontinuous selections - if it did, a discontinuous selection together with an alternate
highlighting routine would be terribly simple and could show all links at once. Lacking
that, the menu seems familiar and straightforward; the only non-obvious detail is that
the link will remain highlighted until the first mouse click.
A dialog box is used by the “Show Link Info” command to show the results of a
census call, to find all the dependencies currently recorded by the IAC driver. Only the
information returned by the census (document ID, hat check, and edition) is displayed;
“size” and content info is likely to be incomprehensible to most applications other
than the originator.
Fundamental Data Structures
In addition to the algorithms all programs implement, the other critical issue in
programming is the selection of data structures. In an application supporting the IAC
driver, 2 additional data structures need to be implemented beyond those needed for the
application’s work: a table of entries for each data extent (simply called the extent
table from now on), and a small group of items that apply to a document as a whole,
rather than to any particular individual extent.
Each entry in the extent table holds the “location” or “size” of the extent so that
the application can determine when its contents have changed; how this is done is
totally application-dependent. This “location” is also necessary so that you can
determine when the user is entering and leaving an extent; as mentioned above this is
important in deciding when to update the IAC driver. It is critical to record the source
document_ID of an extent in order to know where you are the source or a target, and to
identify the extent to the driver. The hat_check is also needed for identification. The
last edition read of the extent is also needed so you can be sure to request its successor.
A “dirty flag” would be a useful extension to further optimize sending data to the
driver.
A certain amount of data needs to be kept about the document as a whole. This
includes the slot_ID for the document, the document_ID, the number of extents for the
document, and a handle to the extent table (although an application that would never
handle more than one document could make the extent table a global data structure
rather than allocating it on the heap).
Program Structure and Style
The IAC Sample Editor was developed in MPW C using MPW 2.0.2 on a
1-Megabyte MacPlus. This was done both because my development environment at
home is identical to my environment at work, and because I am generally quite happy
with MPW (with one caveat mentioned below).
The source code for the sample editor is broken into a number of files, for
several reasons. The first reason is philosophical: working with a number of small,
well-named files is much better when it comes to maintaining code. The second reason
is pragmatic: this approach usually results in faster development, since far less of the
source is processed when a change is made. The final reason is also pragmatic: it was