#432 editor: find word under cursor

  • My cursor is within the word Counter, then after typing Ctrl-F and return, search is ok.
  • Then my cursor is within counter, and after typing Ctrl-F the search window presents me still with the last found Counter instead of counter. I have to change the capital C to lowercase!
  • Then my cursor is within count, and still what I see is Counter.
  • I think, I should always be presented with exactly the word under cursor, because afterwards I'm searching
    I checked with Visual Studio, and there the behaviour is correct.
    Is there a hidden setting, which I don't know ?
    Thanks a lot for every answer, because I need seaching in a big project very often.


  • Teodor Petrov

    Teodor Petrov - 2016-11-12
    • Milestone: Release_xx.yy --> Undefined
    • Hoehener, Ernst

      Hoehener, Ernst - 2016-11-13
      1. version is 16.01
      2. The problem does not depend on a special sourcefile. It happens with any identifier, if you change the spelling later on.
      3. It is most annoying, if you decide to change the spelling via replace f.e. from newflag to NewFlag.
      4. The shortest possible file to test would be a one-liner: int newflag=1; int NewFlag=3;. First put the cursor into the first variable +Ctrl-F + find. Then put the cursor into the second variablename. Again the first variablename is suggested in the search-window after typing Ctrl-F.
      5. No special settings in Editor/General Settings.
  • Teodor Petrov

    Teodor Petrov - 2016-11-12

    Can you show a minimal source file and exact steps for this file to reproduce this?
    Also which version do you use?
    What are the search settings?

  • Teodor Petrov

    Teodor Petrov - 2016-11-13
    1. Doesn't happen with 10912 and wx3 and head and wx2.8. This is on gentoo linux.
    2. I'm not talking about editor settings, but the settings in the find dialog

    Can you try if this problem happens in the latest night build?

  • Hoehener, Ernst

    Hoehener, Ernst - 2016-11-14
    1. My OS is Windows 7.
    2. Find window settings:
    3. Limit to whole word
    4. Match case
    5. Auto-wrap at EOF
    6. Scope: Global
    7. Origin: from cursor
    8. Direction: Down
    9. I will try with the night build, if it is not too difficult (never done it).
  • Hoehener, Ernst

    Hoehener, Ernst - 2016-11-21
    • Well, I tried the night build CB_20160925_rev10912_win32
    • I am very disappointed. Still the same strange behaviour!
    • Teodor Petrov

      Teodor Petrov - 2016-11-21

      @windows users: Can you try to reproduce it?

  • bluehazzard

    bluehazzard - 2016-11-21

    I can confirm this on windows 7 wx2.8
    This seems to be a bug with wxWidgets, because the behaviour is not reproducible with wx3.1

    c::b version used is not latest trunk but quite near (maybe 4-5 commits behind)

    • bluehazzard

      bluehazzard - 2016-11-21

      Future debugging needed if it is a wx bug?

    • Teodor Petrov

      Teodor Petrov - 2016-11-22

      Why do you think it is wx2.8 bug?
      What kind of build are you using?

      • bluehazzard

        bluehazzard - 2016-11-22

        Why do you think it is wx2.8 bug?

        Because it does not appear in wx3.0 and i don't think that there were any changes on the codeblock site related to the search. Actually i think this has something to do with the windows native form of ComboBoxes not to be case sensitive:

        I debugged a bit and i can say that we set the correct value within this line:

        XRCCTRL(*this, "cmbFind1", wxComboBox)->SetValue(initial);

        and the control value is never changed after this call, still a wrong value appears in the combo box in the dialog. So i conclude that the faulty part is on wxWidgets or windows side. But as it seems to work on wx3.0 builds this seems to be a fixed issue on the wx site, although i couldn't find any related bug report by a quick google search.

        [EDIT:] found an old (wx2.4) bug: http://www.devsuperpage.com/search/Articles.aspx?hl=en&G=23&ArtID=266312

        Last edit: bluehazzard 2016-11-22
  • Teodor Petrov

    Teodor Petrov - 2016-11-22
    • labels: editor, search --> editor, search, Windows
  • Teodor Petrov

    Teodor Petrov - 2016-11-22

    Ok, can you try if this happens with older releases? 13.12? 12.05?

  • bluehazzard

    bluehazzard - 2016-11-23

    Why should it work there? In the link i posted, there is described the exact same problem and the link lists a wxWidgets version of wx2.4

    The problem is, that the native Windows ComboBox is case insensitive. If you have a entry in the box called "entry1" and you add a entry with the name "Entry1" on windows the second entry is not added, but the first is selected. And this is exactly the behaviour we see here. Maybe wx3.1 uses a newer interface to a new implementation of the ComboBox where this behaviour is different...

    I see the following possibilities to fix this:
    1. Use wx3.X
    2. Check the ComboBox entry list for case insensitive matches, delete the old entry and add the new one
    3. Reinvent the wheel and implement i custom made ComboBox

    1. Is the obvious way to go
    2. Is kind of implementable but it introduces platform depend code and is not 100% the intended way how this should work, because it alters the search history
    3. Is WAY to much work to fix something already fixed in a newer version....
    • Teodor Petrov

      Teodor Petrov - 2016-11-23

      Editing posts causes confusion... because I've missed the link...

      1 is the only way to go... imo...


Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks