| [ Return to Bugs & Features | SVN ⇄ GIT ]
STR #3241
Application: | FLTK Library |
Status: | 1 - Closed w/Resolution |
Priority: | 3 - Moderate, e.g. unable to compile the software |
Scope: | 3 - Applies to all machines and operating systems |
Subsystem: | Core Library |
Summary: | Suggesting int Fl_Menu_::value() return -1 if last picked item is in a submenu |
Version: | 1.4-feature |
Created By: | greg.ercolano |
Assigned To: | AlbrechtS |
Fix Version: | 1.4.0 |
Fix Commit: | 8ca1e0ca034d083c7ba5a67c7a947093c52dc44e |
Update Notification: | |
Trouble Report Files:
No files
Trouble Report Comments:
|
#1 | greg.ercolano 14:16 Jul 26, 2015 |
| Currently the method:
int Fl_Menu_::value(item)
..returns a wild integer if the item is a member of a submenu (FL_SUBMENU_POINTER).
Since there's no way to return a meaningful index in this case, it should return -1 instead of a wild value.
This shouldn't be hard to do, but it would mean (a) changing the code and (b) documenting the return value used to be wild in older versions and is clamped to -1 in the implemented release. | |
|
#2 | AlbrechtS 10:01 Apr 16, 2024 |
| I believe this could be done in 1.4.x and I also believe it *should* be done because the existing implementation would return an invalid index.
This could even be considered a bug and should be investigated further... | |
|
#3 | AlbrechtS 10:33 Apr 17, 2024 |
| 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. | |
[ Return to Bugs & Features ]
|
| |