Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!utgpu!water!watmath!clyde!cbosgd!ihnp4!ptsfa!lll-tis!mordor!jdb
From: jdb@mordor.UUCP
Newsgroups: comp.sys.mac
Subject: Re: What makes programming the Mac difficult?
Message-ID: <11858@mordor.s1.gov>
Date: Mon, 15-Jun-87 00:15:10 EDT
Article-I.D.: mordor.11858
Posted: Mon Jun 15 00:15:10 1987
Date-Received: Tue, 16-Jun-87 01:18:06 EDT
References: <869@apple.UUCP> <1499@midas.TEK.COM> <6452@dartvax.UUCP> <11573@mordor.s1.gov> <1024@apple.UUCP>
Reply-To: jdb@mordor.UUCP (John Bruner)
Organization: S-1 Project, LLNL
Lines: 48

I don't want to seem argumentative about this (something which is
very easy to do given the nature of the network).  I appreciate that
there are ways to highlight buttons so that update events work.
I'm not happy with any of them.  The default dialog button is
an important part of the user interface, and there should be
a primitive control type for it.  (I think the best approach would
be to use SetCtlValue for this, since the value is not defined
for ordinary buttons.)

I grant that a userItem will work exactly as desired; however,
I feel that using a second dialog item in this fashion is a kludge.
The highlighted button is one conceptual entity.  It shouldn't be
necessary to get the order of two separate dialog items correct
and to move both of them around when creating and editing the dialog.
Nonetheless, it is obvious to me that this is a workable solution
which is likely to be compatible with future software, so I'll
probably start using it.

*Inside Macintosh* indicates that filterProc's can call drawing
routines (it mentions an example with a clock).  Apparently
highlighting the default button before returning the update
event (for ModalDialog to handle) works, but this seems to be
dependent upon the way in which updates are handled (or, more
specifically, upon the way that button controls are updated).
If the update procedure for buttons ever changes so that (e.g.)
the enclosing rectangle is filled with the background color before
the button is drawn, then this method will fail.

I hadn't considered calling DialogSelect from inside a filterProc
(and then highlighting the button after the update even has been
processed), because it seemed like the sort of implementation detail
that one shouldn't depend upon.  The fact that it works with the
current ROMs and System is irrelevant if a future ROM/System change
will break it (I was burned by Megamax and BasicGlob, so I'm
sensitive to this).  If this is an approved technique and isn't
subject to change, then I'll happily start using it in preference
to a userItem.  (In that case, it should also be included in a
technote so that all developers can take advantage of it.)

The larger issue isn't default button highlighting but providing
a framework that shields developers from all of these low-level
user-interface details so that they can concentrate upon their
application-specific problems.  I don't have MacApp yet (I wish
there were a C++ version!), but it sounds as though it may
be the answer.
-- 
  John Bruner (S-1 Project, Lawrence Livermore National Laboratory)
  jdb@mordor.s1.gov	...!seismo!mordor!jdb		(415) 423-4848