This page attempts to answer some of the common questions regarding the menu family, namely:
They are not listed in order of significance.
When the instance is created and initialized, the ‘m_menu’ property is not yet set. Thus, the ‘if’ check in -setKeyEquivalent will not throw an exception.
public function setKeyEquivalent(aKeyEquivalent:String):Void { if(m_menu.isRoot()) { trace(g_rootHasNoKeyEquivalent); throw g_rootHasNoKeyEquivalent; } //... }
The current Mac OS has moved menu support to Carbon, thus they are no longer used. However, in Flash, there is no such equivalent. As a result, ActionStep still provides this deprecated functionality.
Note that the title and key equivalent are displayed together in the same text field. These methods are present in NSMenuItemCell, so that NSMenuView can calculate the largest title and key equivalent width for display.
However, NSMenuItemCell doesn’t need this information, so its rather irrelevent and has been removed as a result.
Images and titles are displayed separately, and this constant doesn’t make any sense. Hence their non-existence.
It cannot display or perform key equivalents.
It cannot :
The following behaviour occurs only when attaching a vertical submenu to another vertical submenu.
The menu checks against the property menu.NSMenuView.bounds():NSSize
The submenu is usually attached to the right of the ancestor menu, but if there is not enough space on the right, it will be attached on the left instead.
The submenu is usually attached such that its y-origin (Flash co-ordinates) will be higher than the ancestor menu, but if there is not enough space vertically, it will be stacked on the bottom of the screen.
The above behaviour is incorrect as it does not take into account the menu’s height, since the top-most items would be obscured from view.
The correct way would be to force a scrollable menu, which has yet to be implemented.