From: ianf@random.se (HyperAgent In Disguise[tm])
Newsgroups: comp.sys.mac.hypercard
Date: Sun, 08 Nov 92 09:03:27 +0100
X-Mailer: Fernmail 1.2b2f
Apparently-To: rnews@sunet.se
Organization: random design -- "Opinions, cheaply"
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