Re: How to halt a running program without losing data?



*** Russell wrote: 
While the use of INQUIRE to test for a user signal is more portable,
the means of posting the signal file using "the "create a file with
some specific name" button on the keyboard still is OS-dependent. Can
you expand on this?


Not really.  "It's OS dependent" is a pretty accurate
statement.  My thought was that the people using a
particular would know how to do this, and that it would be
easier to [re]train them than to maintain a set of
OS dependent subroutines to look for the posted signal.


The only assumption the application needs to make is that there exists
a means for the user to post a signal when dialog is desired. A single
routine can be created to return TRUE if a signal has been posted. The
routine can be called from anywhere in the app at any time, without the
means of detecting the signal being known outside of the routine. The
routine can use an OS-dependent check of a keypress or a portable
INQUIRE about a signal file. If the latter is used, the means of
posting the file itself is OS-dependent. So it seems that some
OS-dependent piece must be devised anyway. The default to be used when
no means of signalling exists is for the routine to return FALSE
always.

I do concede that using INQUIRE on a signal file allows the developer
to create a portable program that can be compiled for the end user's
OS, but someone along the line to the end user must assume the burden
of implementing the means of posting the signal file. As a developer, I
would much prefer to assume this burden myself and distribute an
executable only, targeted for a particular OS, rather than take the
"batteries not included" approach.


Sure, there aren't that many different OSs now.  And if you
can keep the system dependencies straight, that sounds like
a better choice.  The INQUIRE is more of a hack for people
who don't want to take the time to learn about all of the
system calls.

*** Hendrickson

.

Quantcast