Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!cwjcc!tut.cis.ohio-state.edu!ucbvax!hoptoad!tim
From: tim@hoptoad.uucp (Tim Maroney)
Newsgroups: comp.sys.mac.programmer
Subject: Re: Windows menu and DrawMenuBar
Message-ID: <8375@hoptoad.uucp>
Date: 24 Aug 89 00:53:17 GMT
References: <8320@hoptoad.uucp> <15093@dartvax.Dartmouth.EDU>
Reply-To: tim@hoptoad.UUCP (Tim Maroney)
Organization: Eclectic Software, San Francisco
Lines: 79

Thanks to those who've commented by mail and on the network on this
issue.  Most of the responses boiled down to a few points, so I will
try to address those points rather than respond to particular messages
in public.

(1)  The speed of menu updating.  Apparently there are a few programs
which take forever and a day to show their menus after you click in the
menu bar.  I have no idea what they are doing with all that time, but
it seems unlikely they're just consulting RAM data structures and
enabling/disabling menu items.  Even when I do build my Windows menu as
a response to the mouse click, there is no perceptible delay between
the click and the appearance of menus even on a 68000 machine.  Perhaps
the offending applications' data structures are built in such a way
that it takes a long time to access the information of the frontmost
window, but even then, I can't imagine it taking as long as a second.
My best guess is that they are alphabetizing something or touching the
disk.

EnableMenu and DisableMenu merely set a single bit at a fixed offset in
a menu data structure.  I really can't imagine that even a hundred of
them would take a humanly perceptible time.

(2)  Problems with when to fix the menu.  Again, I doubt that even with
ten windows open, there would be a perceptible delay building at the
click.  Unless, that is, you do something stupid like bubble sorting
the menu items in place.  However, just to be sure, I've moved to a
different approach.  There are only two places where I dispose of a
window or dialog, so I rebuild there; and since it is impossible to
create a window in front without generating an activate event, and it
is undesirable to create a window anywhere but in front, I rebuild when
I get an activate event (or a deactivate event) as well.  This seems to
go more than fast enough, particularly since I prefer to present
windows in window list order rather than alphabetically.

Why not do it everywhere I create a window or dialog?  I always create
them invisibly, then have the window-specific module show them when
they've been properly initialized.  There is no single place where
windows enter the list for that reason, though there is a single place
where they're created and have information bound to them.  Therefore,
this is just begging for me (or a developer using my code) to forget
the call to fix the windows menu and introduce a bug -- not a very
serious bug, but one that is not obvious and could easily find its way
into production code.

(3)  The need to call DrawMenuBar.  Those who have pointed out that
this is not necessary are correct.  I was misremembering a bug that
appeared last year when System 6.0 came out, bearing on long menus.
Suppose you delete a short menu and add a longer version of the same
menu.  The appearance of the menu bar doesn't change, so you'd think
the call to DrawMenuBar could be omitted (and so the flicker would be
avoided).  However, apparently System 6.0 caches the menu sizes or
something so that the long menu will be visible only up to the point
where the short menu ended.  I don't know why it didn't happen under
earlier systems.

So -- It is NOT necessary to call DrawMenuBar after adding to or
deleting from a menu.

(4)  Putting symbols into the windows menu.  I don't advise it.  One of
the things I like least about the Mac interface as practiced is the
reliance on cryptic symbols which actually convey far less than text.
FullWrite is a good example; the MPW Shell's use of checks and bullets
and so forth in its Windows menu is another.  Information which is not
asked for by the user should only be ionformation which is readily
comprehensible to the user.

If you must indicate things like who's in front, which windows have
changes, what was the last window you worked on, and so forth, don't
stick confusing symbols (or even worse, style changes) into the Windows
menu.  Instead, come up with a genuinely clear icon or small icon and
put that where it's needed.  Note: a triangle with a dot inside or some
such nonsense is not a clear icon.  Draw something real or don't draw
anything at all -- including a check mark or bullet!
-- 
Tim Maroney, Mac Software Consultant, sun!hoptoad!tim, tim@toad.com

"Its failings notwithstanding, there is much to be said in favor
 of journalism in that by giving us the opinion of the uneducated, it
 keeps us in touch with the ignorance of the community." -- Oscar Wilde