| | [ Return to Bugs & Features | Roadmap 1.3 | Post Text | Post File | SVN ⇄ GIT | Prev | Next ]
STR #2908
| Application: | FLTK Library |
|---|
| Status: | 4 - Pending |
|---|
| Priority: | 2 - Low, e.g. a documentation error or undocumented side-effect |
|---|
| Scope: | 3 - Applies to all machines and operating systems |
|---|
| Subsystem: | Core Library |
|---|
| Summary: | Menu_::find_index(const char*) doesn't handle escape sequence correctly |
|---|
| Version: | 1.3-current |
|---|
| Created By: | Hansen |
|---|
| Assigned To: | greg.ercolano |
|---|
| Fix Version: | Unassigned |
|---|
| Update Notification: | |
|---|
Trouble Report Files:
[ Post File ]
Trouble Report Comments:
[ Post Text ]
| |
| #1 | Hansen
18:18 Dec 15, 2012 |
| Hi, if one wants to use the slash as a text character in a menu item (f.e. the menu items text should be "x/y") one will use a backslash before a slash to prevent the item to be interpreted as a submenu (the escaped char sequence will be "x\\/y").
In that case it is impossible to use the escaped string ("x\\/y") directly to get the index of the menu item because the backslash is not stored in the menu item's class:
SomeMenuWidget.find_index("x/y") works
SomeMenuWidget.find_index("x\\/y") doesn't work!
I already created a patch for fltk-1.3.2 (tested) and for 1.3.x-r9752 (untested but should work!). It simply defines an additional string comparison function which allows both listed cases to work.
cheers Hansen | |
| |
| #2 | greg.ercolano
05:50 Jan 31, 2014 |
| Assigning to me.. I ran into this the other day. | |
| |
| #3 | greg.ercolano
12:28 Jan 31, 2014 |
| Patch might need a few tweaks, as there are a few cases where
strings used to create the menu still don't match with find_index().
Example: an Fl_Choice menu constructed this way:
G_choice->add("c:\\\\a"); // [A]
G_choice->add("c:\\\\a\\\\"); // [B]
G_choice->add("c:\\\\a\\\\b"); // [C]
G_choice->add("c:\\\\a\\\\b\\\\"); // [D]
G_choice->add("c:\\\\a\\\\b\\\\c"); // [E]
..using the patch + find_index() for each of the above same strings,
A,C and E work as expected, but the [B] search string finds [A],
and the [D] search string finds [C].
Also, we may need to support the old behavior, because it's not
documented that the string used to create the menu item is symmetrical.
(For instance if you see c:\foo\bar in the menu, you can find it with
that string using the old behavior, even though c:\\foo\\bar was used
to create it)
To support symmetrical searches, perhaps it would be best to add an optional
parameter to find_index() and find_item() to indicate symmetrical searching
is desired, e.g.
find_index(search); // old behavior
find_index(search, 1); // new behavior for symmetrical search | |
[ Return to Bugs & Features | Post Text | Post File ]
|
| |
