| | [ Return to Bugs & Features | Roadmap 1.3 | SVN ⇄ GIT ]
STR #3177
| 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: | Fl_Menu_::item_pathname() does not handle descending submenu pointers |
|---|
| Version: | 1.3.3 |
|---|
| Created By: | greg.ercolano |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | 1.3.4 (SVN: v10819) |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
Trouble Report Comments:
| |
| #1 | greg.ercolano
10:04 Jan 13, 2015 |
| Fl_Menu_::item_pathname() does not handle descending submenu pointers
(FL_SUBMENU_POINTER).
Seems to be no reason for this, other than recursion is needed to resolve.
Suggest for 1.3.x making a private item_pathname_() method that takes
an optional menu argument, and have the regular item_pathname() call
that. | |
| |
| #2 | greg.ercolano
12:41 Jan 13, 2015 |
| Attaching patch suggestion v1.patch which includes comment mods
to other methods that don't support submenu pointers.
This patch adds a private method that can recurse with different menu
pointers, and the public method simply calls it.
This avoids breaking ABI.
A possible improvement would be to add an ABI feature option so that
when the ABI feature is enabled, the public method simply includes
the optional menu pointer argument, getting rid of the need for the
extra private method. And when the ABI is not enabled, it falls back
to the v1 approach. In this way when 1.4 comes along, the extra private
method can be entirely removed. | |
| |
| #3 | greg.ercolano
12:44 Jan 13, 2015 |
| Attaching test program as test-menu.cxx | |
| |
| #4 | greg.ercolano
13:09 Jan 13, 2015 |
| Meh, v1.patch needs s/SUBMENU_POINTERS/SUBMENU_POINTER/g | |
| |
| #5 | AlbrechtS
06:26 Jan 24, 2015 |
| Changed "Software Version" from 1.1.3 to 1.3.3 (fixing an obvious typo). | |
| |
| #6 | greg.ercolano
10:20 Jun 24, 2015 |
| It should be noted that the menu's value() returns
a huge negative number when items in the submenu are clicked.
While I suppose there is no 'right' answer for value() to return
in this context, the docs for "int value()" should probably reflect
that it can return index numbers less than zero (and possibly greater
than the total menu items?).
At very least, value() should probably be clamped to -1, as I'm
not sure what the huge number is, but it's probably a wild value. | |
| |
| #7 | greg.ercolano
14:10 Jul 26, 2015 |
| Fixed in Subversion repository.
Applied v1.patch with doc mod mentioned in comment #4, and closing.
In closing, also adding test-menu-v2.cxx which exercises the
Fl_Menu_::find_item() return value, to be sure it works as
advertised in new docs (returns -1).
Decided against ABI feature for optional 'menu' argument in the public
interface for now; that seems too confusing for the public interface.
Though I could maybe see a desire for this as a /private/ interface..
letting that go as a future RFE. | |
[ Return to Bugs & Features ]
|
| |
