[STR Closed w/Resolution]

Link:         https://www.fltk.org/str.php?L3241
Version:      1.4-feature
Fix Version:  1.4.0
Git Commit:   8ca1e0ca034d083c7ba5a67c7a947093c52dc44e
Assigned To:  AlbrechtS

Fixed in Git repository.

Changed title: "Suggesting int Fl_Menu_::value(item) return -1 if item is
in a submenu"
to: "Suggesting int Fl_Menu_::value() return -1 if last picked item is in a
submenu"

Fix commit: 8ca1e0ca034d083c7ba5a67c7a947093c52dc44e

Note: the description "int Fl_Menu_::value(item) ..returns a wild integer
if the item is a member of a submenu (FL_SUBMENU_POINTER)" was not correct
which confused me in the first place. The mentioned method would *set* the
"last picked item" to *item*.

The wrong method (the one I fixed) was `int Fl_Menu_::value()` which
returns the index of the "last picked item" which could indeed be "wild" if
that last picked item was in a "detached" submenu addressed by
FL_SUBMENU_POINTER.

There was another incorrectness in the docs, saying that value() was
initially 0. Fact is that the internal Fl_Menu_Item* value_ member was 0
(NULL) but the return value has always been -1 if that was the case. I
fixed the documentation, now saying:

"It is -1 initially (if no item has been chosen) or if the chosen menu item
is part of a submenu addressed by an FL_SUBMENU_POINTER."

Rationale: although the docs were wrong the value -1 had been returned
before. I could have chosen another value (maybe -2) if the picked menu
item was in a "detached" submenu but I decided to use the same value (-1)
for some kind of backwards compatibility. The new menu system planned for
1.5 should address this - I assume that this will not be an issue anyway.

I tested my commit with a modified version of test/menubar.cxx and found
that the value -1 is indeed returned if a menu item of the "huge" menu gets
picked.

I'm closing this STR now with resolution.


Link:         https://www.fltk.org/str.php?L3241