Path: utzoo!utgpu!news-server.csri.toronto.edu!bonnie.concordia.ca!uunet!samsung!think.com!yale!bunker!shap
From: shap@bunker.UUCP (Joseph D. Shapiro)
Newsgroups: comp.windows.ms
Subject: Re: Usher menus are NOT slow.  (and a suggestion)
Message-ID: <17075@bunker.UUCP>
Date: 21 Jan 91 20:19:53 GMT
References: <17074@bunker.UUCP> <6626@mace.cc.purdue.edu>
Reply-To: shap@clunker.UUCP (Joseph D. Shapiro)
Distribution: comp
Organization: ISC-Bunker Ramo, an Olivetti Company, Shelton, Ct
Lines: 61

In article <6626@mace.cc.purdue.edu> dve@mace.cc.purdue.edu (zhou) writes:
] In article <17074@bunker.UUCP> shap@clunker.UUCP (Joseph D. Shapiro) writes:
] >The confusion arises because Usher is a "HOLD DOWN THE LEFT BUTTON"
] 
] 	I don't assume you have a habit of saying things before you under-
] 	stand the facts first. 

I can't tell if this is a flame or not...  :-|

] 	You are talking something entirely irrelevent! Suppose you bring
] 	up Usher and point to a submenu item and cause a submenu display,
] 	then if you draw the pointer to the next submenu of the main menu
] 	you'll have to wait (usually) several seconds before the old submenu
] 	closes and the new
] 	submenu gets displayed to the side. Since when  one passes the
] 	pointer to the desired menu the first menu landed on is not usually
] 	the wanted, and it gets displayed and thus causes delay.
] 	The "Hold down the left button" manner is very good (fast). I
] 	like it very much. The SUN machines here we use all have such menus.
] 
] 	As to the "slow menu" problem, the author has explained that it's
] 	something of windows. I hope he didn't understand me as you did. 
] 	Otherwise I should expect him to look into the matter. I think many
] 	people offen cruise among the menus before letting go (I at least)
] 	So it can a nuisance in the long run.

---

Windows is not a SUN.  If one writes a Windows utility, one should to
conform to windows standards.  All programs which use windows standard
pop-up menus (this is the term used in the SDK, I find it unfortunate)
will exhibit this behavior.  Any program that forces different behavior
onto such a menu will ultimately cause confusion compared to "standard"
programs.

I did offer a clue as to the "standard" way for the user to avoid the
delay, which I will now repeat -- after the first sub-menu comes up,
LET GO OF THE BUTTON.  After that you can click on other sub-menus to
bring them up immediately.  If you do this, you will observe that the
menus are plenty fast.

The fact that you have to hold down the button to keep USHER up makes
it less than natural to let go of the button after the first sub-menu
is up.

As an aside, I do not wish to defend the delay imposed by windows.  I
think that in the whole, there would not be any great waste of CPU to
bring up the menus immediately.  Maybe this is a hold-over from 8086
days, who knows.  I meerly meant to point out that the USHER program
was not imposing the behavior, but inheriting it from windows.

so... even though I don't like the delay either, I think it would be
a mistake to try to "fix" it.

I hope that I have clarified my previous posting, and I hope it is now
clear that I did, and do, understand the facts.
-- 
__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__--__
Joe Shapiro					"My other car is a turbo...
ISC-Bunker Ramo     				 ...too."
{decvax,yale,philabs,oliveb}!bunker!shap