Menuhistory bug?

2002-01-26 Thread David Epstein

Is this a well known bug?  Is it being fixed?

(MC 2.4 under Mac OS 9.2)

A hierarchical pull-down menu does not properly set its menuhistory when a
selection is made from a submenu.  The menuhistory value remains what was
set the last time a selection was made from the first level of the menu.

I know that I can use the parameter passed by menupick to get the contents
of the menu choice and submenu choice; but I want the position of those
choices, because I cannot be sure that the content will unambiguously
indicate the position.  (That is, it is possible that the same content will
appear in several positions yet require a different scripted response).

This is a frustrating bug because the menuhistory DOES at least report the
sub-menu choice position if the button style is popup rather than pulldown.
(Even in this case, however, there is no record of the position of the main
menu choice).  But it appears that for a menu to be part of a group that
will be displayed in the Mac menubar it must have the pulldown style.

Thanks for any insights on this.

David Epstein

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard



Re: Menuhistory bug?

2002-01-26 Thread Scott Raney

On Sat, 26 Jan 2002 David Epstein [EMAIL PROTECTED] wrote:

 Is this a well known bug?  Is it being fixed?

It's a known limitation. We don't classify it a bug because
menuHistory is not a core function of pulldowns or popups, it's
designed for option and tabbed menus.  It's not planned to be changed
because of the way these menus are implemented on MacOS (there is no
place to store the line number information in the MacOS menu
structures).

 (MC 2.4 under Mac OS 9.2)
 
 A hierarchical pull-down menu does not properly set its menuhistory when a
 selection is made from a submenu.  The menuhistory value remains what was
 set the last time a selection was made from the first level of the menu.
 
 I know that I can use the parameter passed by menupick to get the contents
 of the menu choice and submenu choice; but I want the position of those
 choices, because I cannot be sure that the content will unambiguously
 indicate the position.  (That is, it is possible that the same content will
 appear in several positions yet require a different scripted response).

I'd say this is your real problem.  If you have multiple lines that
are identical in a button-contents menu, you've got a serious design
flaw and ought to concentrate on a UI redesign so that this isn't a
requirement.  It's only going to be confusing to the user.  If only
the lowest level elements are identical, it's straightforward to
recover the full path to the line using the lineOffset function (you
just have to step over each |-delimited item in the parameter to
menuPick).

 This is a frustrating bug because the menuhistory DOES at least report the
 sub-menu choice position if the button style is popup rather than pulldown.
 (Even in this case, however, there is no record of the position of the main
 menu choice).  But it appears that for a menu to be part of a group that
 will be displayed in the Mac menubar it must have the pulldown style.

The same limitations should apply to popups in the native look and
feel setting on MacOS, though, because these use the same OS
structures.
  Regards,
Scott

 Thanks for any insights on this.
 
 David Epstein


Scott Raney  [EMAIL PROTECTED]  http://www.metacard.com
MetaCard: You know, there's an easier way to do that...

___
metacard mailing list
[EMAIL PROTECTED]
http://lists.runrev.com/mailman/listinfo/metacard