STR #2908

FLTK matrix user chat room
(using Element browser app)   FLTK gitter user chat room   GitHub FLTK Project   FLTK News RSS Feed  
  FLTK Apps      FLTK Library      Forums      Links     Login 
 Home  |  Articles & FAQs  |  Bugs & Features  |  Documentation  |  Download  |  Screenshots  ]

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
Created By:Hansen
Assigned To:greg.ercolano
Fix Version:Unassigned
Update Notification:

Receive EMails Don't Receive EMails

Trouble Report Files:

Post File ]
Name/Time/Date Filename/Size top right image
#1 Hansen
18:18 Dec 15, 2012
bottom left image   bottom right image

Trouble Report Comments:

Post Text ]
Name/Time/Date Text top right image
#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
bottom left image   bottom right image

Return to Bugs & Features | Post Text | Post File ]


Comments are owned by the poster. All other content is copyright 1998-2024 by Bill Spitzak and others. This project is hosted by The FLTK Team. Please report site problems to ''.