| [ 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 ]
|
| |