Organization: random design -- "Opinions, cheaply"
Lines: 88
Summary: ask not the user & ye shall be rewarded
Subject: Re: Show/hide menubar
A while back NoName <clas005@csc.canterbury.ac.nz> had this
to say in regard to a query by another poster:
# Date: 13 Oct 92 04:07:54 GMT
>>> Although you can use the command "show/hide menubar", HC will not
>>> evaluate the visible state of the menubar. I.e., "the visible of
>>> the menubar" does not return true or false. Does anyone know how
>>> one could construct a button to toggle between showing and hiding
>>> the menubar? Thanks.
>>> --David
>> You could keep a variable containing the state of the menubar.
> But that variable would not be updated if the *user* hide or
> showed the menubar.
> The *simplest* way to do *exactly* what the original questioner
> asked is to ask HyperCard to simulate typing SPACE with the
> COMMAND key held down. This, after all, is the user command for
> toggling the menubar. Just say, "type space with commandKey".
SIMPLE it is.
> If you really need to *know* whether the menubar is visible, there
> is an XCMD that tells you. However, it is not clear to me why you
> need to know this, since you can make sure it is showing by asking
> for show, make sure it is hidden by asking for hide, and toggle by
> the method just described.
I've no quibble with the toggle-menubar-method described, simple
though it may be. I would, however, object to an implementation
that NoName seems to be favouring: to require explicit end-user
interaction ("ask for show"; "ask for hide") ) for such simple-
minded tasks as these.
This seems to me just another example of the common widespread
misconception as to what is, or should be, the essence of user
interaction and --in a wider sense-- that of programming and
computing itself.
My opinion of the first (the need and extent of user interaction)
is that end-users should only be asked to supply explicit anwers
or expected to make decisions in matters of essence or of great
importance. All the other "administrative" actions should be
taken care of by the program itself, with a minimum of needless
user interaction and/ or notification. It is by protecting the
users from simplistic tasks like these, not by offering them an
illusion of being "in control at all times," that they best be
served.
If the designer of a program (in this case of a stack) considers
showing or hiding of a menubar to be of importance, requiring the
user to press a button to toggle it on and off, then perhaps s/he
ought to reconsider the design itself.
A better course of action would be to draw up conditions under
which the menubar should remain off (or on) and then to trap, and
continuously check for, occurencies of those conditions. Once
detected, take the default action without any explicit involvement
by the user. Include a toggle button, by all means, but treat it
solely as a secondary mechanism, a "menuBar display undo" sort of.
In this particular case, menuBar status could easiest by tracked
and transformed by the following handler:
on myEvent ---------------say 'openCard'
if menubarIsShowing() --XFCN by Eric Carlson, (c) Apple 1990;
then hide menuBar ------included in Support Tools eXternals 1.2.5
else show menuBar ------stack [Apple's spelling, not mine]
end myEvent
Those among you wanting to ensure that no end-user ever be able
to find and delete that eternal piece of code from one of your
scripts may elect to do the same thing in the following highly-
obfuscated inline fashion:
do&&(item offset(char 1 of menubarIsShowing(),"tf") of "hide,show)&&"menubar" --add a confusing comment like "MAKING SURE THE DATA ARE SECURE" or something; (c) Basil Fawlty School of Advanced Programming Logic, Summer Course '92
After all, isn't protecting the user from mundane tasks like
having to decide whether or not the menubar should be on just
what 'programming' should be all about?
__Ian "name of the game is 'Five Card Stud'" Feldman
