erich@crash.cts.com (Eric Hicks) (03/01/91)
Just a quick question that is quite probably rather simply solved. An
application I'm writing never uses the edit menu while my main window
is frontmost. (ie active) I've dimmed the menu, which is easily accomplished
in ResEdit. My problem occurs with DA suppport. I can enable the menu
when the DA comes up easily, and I also figured out how to tell when the
user has chosen close from my file menu as a way to close a DA. My Problem
occurs when the user, clicks the close box of a DA. How can I find out
when this has happened so that I can dim the edit menu? I have a solution
that "works" but it's so ugly that it's not worth posting. E-mail response
is fine and I'll summarize to the net if there seems to be a need and the
solution isn't obvious. Code fragments in either Pascal or C are fine, as
they are relatively easy to inter-translate. If it's any help, I'm using
THINK C 4.0. Thanks in advance...
--
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>
< UUCP: {nosc ucsd hplabs!hp-sdd}!crash!erich >
< ARPA: crash!erich@nosc.mil >
< INET: erich@crash.cts.com >
< DISCLAIMER: My opinions are a figment of your imagination. >
< "At last, after 2000 years of work, the Eludium PU-36 >
< explosive space modulator." >
<><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><><>jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) (03/03/91)
Eric Hicks writes in a message to All
EH> Just a quick question that is quite probably rather simply solved.
EH> An application I'm writing never uses the edit menu while my
EH> main window is frontmost. (ie active) I've dimmed the menu, which
EH> is easily accomplished in ResEdit. My problem occurs with DA
EH> suppport. I can enable the menu when the DA comes up easily,
EH> and I also figured out how to tell when the user has chosen close
EH> from my file menu as a way to close a DA. My Problem occurs when
EH> the user, clicks the close box of a DA. How can I find out when
EH> this has happened so that I can dim the edit menu? I have a solution
EH> that "works" but it's so ugly that it's not worth posting. E-mail
EH> response is fine and I'll summarize to the net if there seems
EH> to be a need and the solution isn't obvious. Code fragments in
EH> either Pascal or C are fine, as they are relatively easy to inter-translate.
EH> If it's any help, I'm using THINK C 4.0. Thanks in advance...
You should be disabling the menu whenever the DA's window is not in front. In your main event loop, check FrontWindow. If it is your window, then disable the menu.
--
Jim Spencer (jspencer@mmug.edgar.mn.org)
[Do not use the @p510.f22.n282.z1.mmug.edgar.mn.org to reply - bounces mail]
UUCP: ...jhereg!tcnet!vware!edgar!mmug!jspencer
FidoNet: 1:282/22.510
--jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) (03/06/91)
jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) writes: > Eric Hicks writes in a message to All > > Just a quick question that is quite probably rather simply solved. > > An application I'm writing never uses the edit menu while my > > main window is frontmost. (ie active) I've dimmed the menu, which > > is easily accomplished in ResEdit. My problem occurs with DA > > suppport. I can enable the menu when the DA comes up easily, > > and I also figured out how to tell when the user has chosen close > > from my file menu as a way to close a DA. My Problem occurs when > > the user, clicks the close box of a DA. How can I find out when > > this has happened so that I can dim the edit menu? I have a solution > > that "works" but it's so ugly that it's not worth posting. E-mail > > response is fine and I'll summarize to the net if there seems > > to be a need and the solution isn't obvious. Code fragments in > > either Pascal or C are fine, as they are relatively easy to translate > > If it's any help, I'm using THINK C 4.0. Thanks in advance... > >You should be disabling the menu whenever the DA's window is not in front. >In your main event loop, check FrontWindow. If it is your window, then >disable the menu. > > Jim Spencer (jspencer@mmug.edgar.mn.org) this will only chew up processor time, checking many times a second. what youneed to do is when the user clicks on a close box, call TrackGoAway, then if true, check if it is yours or a DA's. if a DA's, dim the Edit menu and call CloseDeskAcc. for other cases, dim the Edit menu when your windows are activated, and undim it when they are deactivated. .....Jeff
d88-jwa@byse.nada.kth.se (Jon W{tte) (03/06/91)
In article <> jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) writes: +-jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) writes: +-+- Eric Hicks writes in a message to All +-+- +- Just a quick question that is quite probably rather simply solved. +-+- +- An application I'm writing never uses the edit menu while my +-+- +- main window is frontmost. (ie active) I've dimmed the menu, which +-+- +- is easily accomplished in ResEdit. My problem occurs with DA +-+- +- suppport. I can enable the menu when the DA comes up easily, +-+-You should be disabling the menu whenever the DA's window is not in front. +-+-In your main event loop, check FrontWindow. If it is your window, then +-+-disable the menu. +-this will only chew up processor time, checking many times a second. what +-youneed to do is when the user clicks on a close box, call TrackGoAway, +-then if true, check if it is yours or a DA's. if a DA's, dim the Edit menu Bzzzzt. I'm sorry. You were all very close, but step down behind the curtains and we'll have some fabulous consolation prizes for you. The right answer is, of course, to check the windowKind of the FrontWindow just before you call MenuSelect or MenuKey - it's that simple. There won't be any noticeable delay before the menu appears either (not even on the Classic...) This is the way it's done in the Think Class Library, among other places. h+@nada.kth.se Jon W{tte "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki in comp.sys.mac.programmer
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/06/91)
In article <1991Mar6.074201.13324@nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: >The right answer is, of course, to check the windowKind of the >FrontWindow just before you call MenuSelect or MenuKey - it's >that simple. There won't be any noticeable delay before the menu >appears either (not even on the Classic...) You mean you would have a greyed-out menu that blackens when you press on it? Why would a user press on a grey menu? This strikes me as a Bad Idea. It would be ok for menu items, but not for entire menus. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
zben@ni.umd.edu (Ben Cranston) (03/07/91)
In article <1991Mar6.074201.13324@nada.kth.se> d88-jwa@byse.nada.kth.se (Jon W{tte) writes: > Bzzzzt. I'm sorry. You were all very close, but step down behind > the curtains and we'll have some fabulous consolation prizes for > you. Mighty gratuitous, especially since you COMPLETELY misunderstood the actual subject of this thread... > The right answer is, of course, to check the windowKind of the > FrontWindow just before you call MenuSelect or MenuKey - it's > that simple. There won't be any noticeable delay before the menu > appears either (not even on the Classic...) I've used this technique, though accidently omitting the check before MenuKey introduced a very subtle bug in one of my applications. This approach works fine for turning menu ITEMS (the things that only appear when you mouse down on the menu TITLE bar) on and off, since they are not visible until MenuSelect is called. However, the subject of this thread is making the menu TITLES, which are visible ALL THE TIME, dim and light. According to user interface rules when all the choices are dim the menu title itself should dim, if any choice is possible the menu title should be lighted. The quoted solution does NOT address this problem... As I said in private mail to the original poster, I've approached this problem by writing a "fixmenu" routine that examines FrontWindow and typically branches into three cases. In the case that FrontWindow is completely null (no windows on the screen at all) typically only OPEN and QUIT in the FILE menu get lit. If FrontWindow is one of MY windows then I do whatever is necessary, if not then FrontWindow is a DA window and I setup the menus for that case. I call "fixmenu" on every activate and deactivate event. When the front window changes you should get one or the other most of the time. The bad case is when there are none of your windows at all and a DA comes and goes. I could not think of a better solution than calling "fixmenu" after EVERY call to SystemClick. This causes the menu bar to blink with each DA click though. Sorry, I cannot think of a better solution than trapping a changing FrontWindow in the main event loop that will handle all cases. If anybody out there UNDERSTANDS the problem and has a better solution please post it. Ben Cranston <zben@umd2.umd.edu> Computer Science Center Network Infrastructures Group University of Maryland at College Park of Ulm "The good news is that Saddam Hussein will be prosecured for war crimes." "The bad news is that it will be before the Senate Ethics Committee..."
hairston@henry.ECE.CMU.EDU (David Hairston) (03/07/91)
[jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) writes:] [] Eric Hicks writes in a message to All [] [] EH> Just a quick question that is quite probably rather simply solved. [] EH> An application I'm writing never uses the edit menu while my [] EH> main window is frontmost. (ie active) I've dimmed the menu, which [] EH> is easily accomplished in ResEdit. My problem occurs with DA [] EH> suppport. I can enable the menu when the DA comes up easily, [] EH> and I also figured out how to tell when the user has chosen close [] EH> from my file menu as a way to close a DA. My Problem occurs when [] EH> the user, clicks the close box of a DA. How can I find out when [] EH> this has happened so that I can dim the edit menu? I have a solution [] ... stuff deleted ... [] [] You should be disabling the menu whenever the DA's window is not in front. [] In your main event loop, check FrontWindow. If it is your window, then [] disable the menu. you should adjustMenus() just prior to grabbing an event in your main loop. this action keeps your menu interface uptodate with respect to the front window. however, don't go overboard in adjustMenus(). you can determine the "kind" of window in front by using FrontWindow() and checking the value of ((WindowPeek) frontWindow)->windowKind. if this is negative the front window is a system window (i.e. a DA window). if this value is 2 then the window is an alert/dialog window. if this value is 8 (or better, you can set it yourself) then its an application window. when disabling/enabling an entire menu don't forget to DrawMenuBar() to show the change (you don't want to DrawMenuBar() for every call to adjustMenus(), just when the menu bar needs updating). for more details see Inside Macintosh Vol. I, Chap.s 9 & 11 (Window & Menu Managers). -dave- hairston@henry.ece.cmu.edu
lippin@twinkies.berkeley.edu (The Apathist) (03/07/91)
In many articles, people write:
<Ideas on ways to keep the menu enabling/disabling current>
The method I've found best for doing this is:
1) Keep a "menus may be out of date" flag.
2) Have a routine which checks the flag, and when it is set,
updates the menu enablements and clears the flag.
3) After an event which may change the enablements, set the flag.
(Which events are included here depend on the application.
For example, if you disable cut/copy/clear when a text
selection is empty, clicks and keys can change it. It's
probably best to be liberal here, except for null events, as
might be needed for a "Stop" command.)
4) If the flag is set, use a zero sleep time in WaitNextEvent.
5) On a null event, if the flag is set, call the updating
routine, and go back for another event.
6) When you get a click in the menu bar or a command key, call
the updating routine before handling it.
This method ensures that, no matter how complex your menu enabling is,
most actions aren't slowed down by it, because the updating is done at
idle time. The fourth clause ensures that the user won't be looking
at out of date menus while deciding what to do next, and the sixth
clause ensures that the menus are up to date when they're actually
used.
--Tom Lippincott
lippin@math.berkeley.edu
"But let me repeat myself, at the risk of being clear:
There must be fifty ways to write your program."d88-jwa@byse.nada.kth.se (Jon W{tte) (03/07/91)
In article <> zben@ni.umd.edu (Ben Cranston) writes: >> Bzzzzt. I'm sorry. You were all very close, but step down behind >> the curtains and we'll have some fabulous consolation prizes for >> you. >Mighty gratuitous, especially since you COMPLETELY misunderstood the >actual subject of this thread... Hmm... yeah... Well, I don't like TV much anyway :-) >thread is making the menu TITLES, which are visible ALL THE TIME, dim >and light. According to user interface rules when all the choices are Ooops. I forgot to say, call it at every (de)activate event... >As I said in private mail to the original poster, I've approached this >problem by writing a "fixmenu" routine that examines FrontWindow and >I call "fixmenu" on every activate and deactivate event. When the front >Sorry, I cannot think of a better solution than trapping a changing >FrontWindow in the main event loop that will handle all cases. If >anybody out there UNDERSTANDS the problem and has a better solution >please post it. Well, now that I _UNDERSTAND_, please let me suggest: On deactivate: set a "clear menu flag" to 3 On activate: Hilight menu titles as appropriate In event loop: Decrease flag one. If _transition to 0_ occurs disable menu. If user clicks in menu _after_ deactivate but _before_ "clear menu flag" goes up, make an explicit check. This way, you usually don't have a menu that flickers on/off at each window change, but still behaves reasonably well. (except for a menu title that goes from black to grey when clicked upon _if_ the user clicks on the item within 1/20th of a second after he closed the last window. Yeah.) Or you could continuously monitor FrontWindow through your event loop, and check the windowKind field when _that_ changes (if you don't trust the mac to bring you activate and deactivate events for DAs...) Gee, or you could use the Think Class Library and forget about all that stuff, as I have :-) h+@nada.kth.se Jon W{tte -- "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki in comp.sys.mac.programmer "The IM-IV file manager chapter documents zillions of calls, all of which seem to do almost the same thing and none of which seem to do what I want them to do." -- Juri Munkki in comp.sys.mac.programmer
bin@primate.wisc.edu (Brain in Neutral) (03/08/91)
From article <1991Mar6.174029.4706@ni.umd.edu>, by zben@ni.umd.edu (Ben Cranston): > I call "fixmenu" on every activate and deactivate event. When the front > window changes you should get one or the other most of the time. The bad > case is when there are none of your windows at all and a DA comes and > goes. I could not think of a better solution than calling "fixmenu" > after EVERY call to SystemClick. This causes the menu bar to blink with > each DA click though. Do also have the problem that when you have only one window and it goes away, there is no deactivate? When I've tried to solve this problem, I think I ended up having to mess with menus on activates/deactivates and window closes. It's an ugly problem. There's no need to make the menu bar blink unnecessarily, though. Check bit 0 of the menu flags word to see what the state of a menu is, *then* figure out what it *should* be. If they differ, then you need to redraw the menu bar after the menu and its items are set properly, otherwise you don't need to. This way, the menu bar blinks only when a menu state changes. -- Paul DuBois dubois@primate.wisc.edu
dorner@pequod.cso.uiuc.edu (Steve Dorner) (03/08/91)
In article <1991Mar6.174029.4706@ni.umd.edu> zben@ni.umd.edu (Ben Cranston) writes: >goes. I could not think of a better solution than calling "fixmenu" >after EVERY call to SystemClick. This causes the menu bar to blink with >each DA click though. You're missing something obvious, as is the "count backwards from 3" poster. Your fixmenu routine should CHECK the current state of the menus in the bar, and only redraw the bar if it needs to change any of them. Call it as often as you like, and it won't flicker. -- Steve Dorner, U of Illinois Computing Services Office Internet: s-dorner@uiuc.edu UUCP: uunet!uiucuxc!uiuc.edu!s-dorner
Lewis_P@cc.curtin.edu.au (Peter Lewis) (03/08/91)
In article <1991Mar6.174029.4706@ni.umd.edu>, zben@ni.umd.edu (Ben Cranston) writes: > As I said in private mail to the original poster, I've approached this > problem by writing a "fixmenu" routine that examines FrontWindow and > typically branches into three cases. In the case that FrontWindow is > completely null (no windows on the screen at all) typically only OPEN and > QUIT in the FILE menu get lit. If FrontWindow is one of MY windows then > I do whatever is necessary, if not then FrontWindow is a DA window and I > setup the menus for that case. This procedure can also examine any other state dependend information (eg, what the application is doing at the moment, what features are enabled, whether the document has been modified). > I call "fixmenu" on every activate and deactivate event. When the front > window changes you should get one or the other most of the time. The bad > case is when there are none of your windows at all and a DA comes and > goes. I could not think of a better solution than calling "fixmenu" > after EVERY call to SystemClick. This causes the menu bar to blink with > each DA click though. As I explaned in Email to the orignal poster, I simple call this every time round the event loop. To avoid flicker, I keep a shadow of the editMenuEndabled state, and only redraw the menu bar if it changes. I don't have any problem with flicker, and I work on a Plus, and I dont have any speed problems (after all, the OS routines called in the fixmenu (I call it SetMenus) are all VERY simple (read/write a field in a record)). Clearly if you were inclined, you could track down all the places where your internal state changes, and track FrontWindow, and only call fixmenus when any of them changed, but its much simpler and less error prone to simply call it every time round the event loop. One problem I did have, was that I had not enabled suspend/resume events, so my app lit the edit menu up when it was switched out (because someone elses document window was there), and left it lit when I was switched back, even though there was no window. It dimmed as soon as an event occured, so enabling suspen/resume events fixed up the problem). HTH, Peter. -- Disclaimer:Curtin & I have an agreement:Neither of us listen to either of us. *-------+---------+---------+---------+---------+---------+---------+-------* Internet: Lewis_P@cc.curtin.edu.au I Peter Lewis Bitnet: Lewis_P%cc.curtin.edu.au@cunyvm.bitnet I NCRPDA, Curtin University UUCP: uunet!munnari.oz!cc.curtin.edu.au!Lewis_P I GPO Box U1987 AppleLink: Guy Kawasaki for Apple President! I Perth, WA, 6001, AUSTRALIA Has anyone ever found someone who used a Mac and then Changed To a PC?
jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) (03/09/91)
d88-jwa@byse.nada.kth.se (Jon W{tte) writes: > In article <> jeffb.bbs@shark.cs.fau.edu (Jeffrey Boser) writes: > > jspencer@p510.f22.n282.z1.mmug.edgar.mn.org (Jim Spencer) writes: > > > Eric Hicks writes in a message to All > > > > Just a quick question that is quite probably rather simply solved. > > > > > An application I'm writing never uses the edit menu while my > > > > main window is frontmost. (ie active) I've dimmed the menu, which > > > > is easily accomplished in ResEdit. My problem occurs with DA > > > > suppport. I can enable the menu when the DA comes up easily, [various responses, including mine, deleted] > The right answer is, of course, to check the windowKind of the > FrontWindow just before you call MenuSelect or MenuKey - it's > that simple. There won't be any noticeable delay before the menu > appears either (not even on the Classic...) no, this is very wrong. ok, in full, here is what should be done: deactivation or closing of your window: undim the edit menu activation of your window: dim the edit menu you can find out what window it is by checking the windowKind field of the window's record (negative if it is the DA's) if a DA is closed, another might be beneath it, so do not dim the menu. if your window is opened, it will generate an activate event (if you create it invisible and ShowWindow() it) if a DA is opened, it will generate a deact for your window the problem with your way is that it deals only with menu items. according to the HINs, if an entire menu is innappropriate, dim it. besides, dimming all of the items only works on the first 32 (i think). > This is the way it's done in the Think Class Library, among > other places. actually the Think Class Lib uses this method for specific menu *items* not menus. and the Think Class Library is more than a bit flakey in some areas. if you are writing anything worthwhile, it might be best to use TCL only as a base, and build your own.
hairston@henry.ECE.CMU.EDU (David Hairston) (03/11/91)
[Eric Hicks writes in a message to All]
[] Just a quick question that is quite probably rather simply solved.
[]
[] An application I'm writing never uses the edit menu while my
[] main window is frontmost. (ie active) I've dimmed the menu, which
[] is easily accomplished in ResEdit. My problem occurs with DA
[] suppport. I can enable the menu when the DA comes up easily,
i thought this had died but apparently there's still some confusion.
if you are interested in a "simple" solution then model your event loop:
while (! done)
{
adjustMenus();
WaitNextEvent(...);
...
}
adjustMenus() keeps your total menu interface uptodate with the current
front window by noting the windowKind field, as mentioned before.
adjustMenus() should be efficient and be able to determine the
state of the menu bar and menus given the front window. adjustMenus()
should also remember its previous state and only do work when the
menu state changes (i.e. in the simplest case when the front window
changes). keep in mind that when the menu bar changes state (i.e. the
Edit menu is disabled) then you need to DrawMenuBar() to reflect the
change. there may be situations where only the menus change and the
menu bar doesn't.
this approach is responsive, does not cause the menu bar to flicker,
accurate with respect to being uptodate and easily managed and works
for any type of front window. it seems to be a simple alternative.
it also keeps your activeEvt and etc. handling simple.
-dave-
hairston@henry.ece.cmu.eduzben@ni.umd.edu (Ben Cranston) (03/12/91)
In article <4017@uakari.primate.wisc.edu> bin@primate.wisc.edu writes: > Do also have the problem that when you have only one window and it goes > away, there is no deactivate? When I've tried to solve this problem, > I think I ended up having to mess with menus on activates/deactivates > and window closes. It's an ugly problem. Paul brings up a very good point. If there is exactly one window on the screen and it is CLOSED (i.e. destroyed) there will be no deactivate event because it is not going to the back, it is going AWAY. Since there is no other window to be brought forward, there will be no activate event either. But, you still need to get the menu enables updated. I suppose you could put a call to FixMenu in whenever you close a window, but then the problem of detecting a close to a Desk Accessory comes up again. Expecially if the Desk Accessory can "close itself", maybe with a button the application cannot know about or even an explicit call to CloseDeskAcc from within itself. The alternative of checking for a changed FrontWindow() in the main event loop and keeping track of the menu state really changing to supress blinking starts sounding better and better. > There's no need to make the menu bar blink unnecessarily, though. Check > bit 0 of the menu flags word to see what the state of a menu is, *then* > figure out what it *should* be. If they differ, then you need to redraw > the menu bar after the menu and its items are set properly, otherwise you > don't need to. This way, the menu bar blinks only when a menu state changes. If you're careful you can do this with just two flags rather than one flag per menu. One saves the pre-modification state of the menu you are currently updating, if the update changes the state of the menu the second flag gets set. At the end, if the flag is set, you need to do a DrawMenuBar. N.B. it looks like from a close reading of the Window and Event manager chapters that you actually DO see activate and deactivate events for DAs but GetNextEvent returns false, so an event loop that requires a true response would never notice them.
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (03/12/91)
Why not allow the Edit menu to be active when your none of your windows are
open (at least I think that's what you said you were NOT doing)? If the user
wants to edit something that doesn't exist, well, let him. You should only be
concerned with the cases where the user might be confused: if there is no window
open, there is nothing there to edit, and even the most naive user wouldn't
be confused when nothing happens when he selects "Paste," that way, your need
to activate/deactivate the menu has been simplified.
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.orgbin@primate.wisc.edu (Brain in Neutral) (03/14/91)
From article <4746.27DDB39B@stjhmc.fidonet.org>, by Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English): > wants to edit something that doesn't exist, well, let him. You should only be > concerned with the cases where the user might be confused: if there is no window > open, there is nothing there to edit, and even the most naive user wouldn't > be confused when nothing happens when he selects "Paste," that way, your need > to activate/deactivate the menu has been simplified. You'd be surprised what can confuse users. For instance, one might ask "why does this stupid machine let me select Edit menu items when there's nothing to edit? Huh? Huh?" Remember, some people do not even understand how to double-click, even after several sessions of working on a Macintosh. (Yes, I observe this.) -- Paul DuBois dubois@primate.wisc.edu
hairston@henry.ECE.CMU.EDU (David Hairston) (03/16/91)
[Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) writes:] [] Why not allow the Edit menu to be active when your none of your windows are [] open (at least I think that's what you said you were NOT doing)? ERROR: bad human interface ... -dave- hairston@henry.ece.cmu.edu
Lawson.English@p88.f15.n300.z1.fidonet.org (Lawson English) (03/17/91)
Brain in Neutral writes in a message to All
BIN> You'd be surprised what can confuse users. For instance, one
BIN> might ask "why does this stupid machine let me select Edit menu
BIN> items when there's nothing to edit? Huh? Huh?"
BIN> Remember, some people do not even understand how to double-click,
BIN> even after several sessions of working on a Macintosh. (Yes,
BIN> I observe this.
I thought about my reply later and came to the same conclusion (silly me, follow
the Human Interface Guidelines!). I've met several people who don't consider
themselves Mac experts: "I've attended a few seminars, but I don't understand
much about using it yet..."
Speaking of UserInterface violations, did you read the "Hot Keys" artcle in
Spring Issue of MacTech Journal? It gives an "intuitive" way of adding hot keys
to dialogs by searching the control list for titles and allowing the user to
press the first letter of the title to activate the button. "o" for "OK" and
"c" for "Cancel" are the examples given. Shades of Windows! (This article is
a Norton Utilities plug, BTW). I guess none of the programmers remembered that
cmd-C and cmd-O already had meanings, or maybe we are supposed to remember that
whilest using Norton, these keys have new, non-standard meanings (my "intuitive"
way of using "hot keys" is to press the command key first, but I guess I'm not
part of their targeted market).
It's all part of a MicroSoft plot to dilute the Mac by making it more Windows-like...
Lawson
Lawson
--
Uucp: ...{gatech,ames,rutgers}!ncar!asuvax!stjhmc!300!15.88!Lawson.English
Internet: Lawson.English@p88.f15.n300.z1.fidonet.org