corre@csd4.csd.uwm.edu (Alan D Corre) (06/08/90)
I should like to say something about a feature of ProIcon windows which can
potentially cause a bug in programs which may go undetected for some time,
and then cause the program to fail at a distance from the causative event,
leaving the user with a cryptic error message.
A window is opened by the function wopen() which assigns an integer to
identify the window, and returns this integer as its value. In this respect
it is not parallel to open() which returns a file value. The window can be
closed with wclose(). This is where the problem arises. If the user closes
the window by clicking on the box, and then the program attempts to close
the window, there is a "hole" in the roster of windows, and the variable to
which the integer is assigned has the same value, but no longer references a
window. This causes an error.
There are several ways in which this can be handled. One is always to attach
windows to files by opening the window as a file. In this case the window is
hidden rather than dismissed, and no error will be caused. But this changes
the rules of the game, and does not permit the user to dismiss the window,
which under some circumstances might be desirable. An alternative solution
is to routinely use wopen() again before using wclose() or indeed before any
window function. If the window is still open, wopen() will simply return an
integer. If it is not, it will give wclose() something to work with. A final
possibility might be to give &error a positive value, changing the error to
a failure. This is not recommended, since &error is meant as a debugging
aid, allowing programs to limp home if errors are encountered. In such cases
the final value of &error should always be checked and adjustments made. At
this point I add a "tangent" which discusses an essentially different issue.
Tangent
The TopSpeed Modula-2 Language Tutorial (p. 27) contains a program to
reverse an integer using arithmetic rather than string methods:
...
BEGIN
WrStr("Enter number to be reversed: ");
number := RdCard();
WrStr("The reversal is: ");
REPEAT
WrCard(number MOD 10, 1);
number := number DIV 10
UNTIL number = 0;
WrLn
END
...
I tried entering a non-integer, A79 for example. The program accepted the
bad data gladly, and gave me a garbage answer. I wrote and asked the company
what was the point of the strict typing of RdCard() which on its face will
only read a cardinal number, if it accepts A79? The answer: It's the job of
the programmer to protect against that. A global variable OK is set to FALSE
in such a case. Fine, but who knows about it?
It's curious how the inventor of a language has fanatically strict typing,
stricter than Pascal, and it is subverted by the implementor. Obviously
programmers dislike such strict rules, and call for modification which is
supplied to them. It seems to me that Icon makes a lot more sense. That
program translated into Icon would fail by default. The arithmetic operator
would take care of it. You would have to TELL &error explicitly that you
wanted the Modula-2 situation to prevail--and that is how &error should be
used.
--
Alan D. Corre
Department of Hebrew Studies
University of Wisconsin-Milwaukee (414) 229-4245
PO Box 413, Milwaukee, WI 53201 corre@csd4.csd.uwm.eduyost@esquire.UUCP (David A. Yost) (06/08/90)
In article <4356@uwm.edu> corre@csd4.csd.uwm.edu (Alan D Corre) writes: >If the user closes >the window by clicking on the box, and then the program attempts to close >the window, there is a "hole" in the roster of windows, and the variable to >which the integer is assigned has the same value, but no longer references a >window. This causes an error. The right way to handle this, I think, is for an icon procedure to be called when the user clicks the close box. Which is to say that opening a window should do more than return an integer; it should hook some procedures to be called when the user does certain things to the window. --dave yost yost@dpw.com or uunet!esquire!yost Please ignore the From or Reply-To fields above, if different.