Scott Raney <[EMAIL PROTECTED]> wrote, in response to my question about
the keyboard behavior of the answer dialog:

>This is standard Windows and Motif behavior: the underlined character (the
>mnemonic) specifies what button will be activated when you press that
>character
>when no field has the keyboard focus.  It is indeed an undocumented feature
>that this also works in the MacOS look and feel.  I wouldn't count on this
>behavior, though: if people start reporting it as a bug (and they haven't so
>far), it could change.

So that's the story.  I am Mac user and have just a little experience with
Windows and none with Unix.  I had not noticed this feature on Windows.
Now that I do, I see that I have a little fixing to do.  The one dialog box
offers the user the options of a "Complete" or "Endgame" or "Buttons"
scramble, plus the option to "Cancel".  On Windows, the dialog box
underlines the "C" as the mnemonic for both "Complete" and "Cancel".  The
"c" key gives "Complete".

Since MetaCard doesn't resolve the conflict when two options start with the
same letter, I suppose I need to change my terminology, say replace
"Complete" with "Total".


Scott went on and gave lots of good ideas about good UI development practice:

> > My question:  Is there a better way to do what I am trying to do here.
> > Does anyone see any pitfalls with this approach? (I am nervous because I
> > find nothing in the documentation that this is how autoArm is supposed to
> > work for a button.)
>
>My first reaction would be yes: you probably should be using an option menu
>for this choice instead of opening a dialog.  UI hacks like having people
>hold keys down to change the behavior are just bound to get you in trouble
>at some point, even if you do only plan to document them for the expert user
>(e.g., some non-expert user will undoubtedly run into it and file a bug report
>about this unexpected behavior).  A group of radio buttons or a list box could
>also be used for this.  And never open dialogs one after another for a common
>operation: make one dialog with all the settings for that operation in it
>instead.
>
>There is a way to solve your problem, though, if you insist on experimenting:
>handle the rawKeyDown message in a frontScript and check the target as the
>first
>step in the handler.  If it's one you know how to deal with, do your thing.
>Otherwise "pass rawKeyDown".
>   Regards,
>     Scott
>
>--
>********************************************************
>Scott Raney  [EMAIL PROTECTED]  http://www.metacard.com
>MetaCard: You know, there's an easier way to do that...

Good food for thought here.  Thanks for giving us the benefit of your
experience.  As I polish up these puzzles, I ought to be streamlining the
user's experience by using option menus, etc.

John Kiltinen


++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
 John Kiltinen ([EMAIL PROTECTED])        Home              Office
 Professor, Dept. of Math. & CS   Tel.(906) 228-8035 or (906) 227-1600
 Northern Michigan University     Fax (906) 228-4667 or (906) 2272010
 Marquette, MI 49855 USA
++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++



Archives: http://www.mail-archive.com/[email protected]/
Info: http://www.xworlds.com/metacard/mailinglist.htm
Please send bug reports to <[EMAIL PROTECTED]>, not this list.

Reply via email to