BTW, I've just checked that reverting the fix will not create that bug.
I'm reverting it. Thanks for the post.
I'll have to respecfully disagree again. Reverting the fix does indeed create bug 10992 on my (msw) system.
I'm not sure it's a bug though.
But the problem is not the "."(s) as reported. "&"s or any other word break will cause the problem also. Which makes this a text range, not just a text word.
I think that find believes it is actually finding what was requested.
If you follow the bugs description, you will notice that when you mark the text, then use Ctrl-F, "selected text" is checked and enabled. So Ctrl-F/F3 is doing exactly what it was told to do.
The next time you hit Ctrl-F, the "selected text" box is disabled. So Ctrl-F and F3 finds the next item.
Find is only looking in the "selected text"
I'm not sure there's a bug actually.
If find is to act as the bug reporter expects, "selected text" must be turned off, even tho the user marked text.
Should we always uncheck "selected text" whenever find dlg is invoked?
Original description:
With the following code you can reproduce the bug. Add an empty file and type
addr.sin
addr.sin1
addr.sin2
then mark addr.sin with the mouse and then call the Find dialog using Crtl+F or Search->Find. The content addr.sin is put in the find dialog, but if you press now F3 you will get no search results.
If you mark addr.sin again with the mouse and use again Ctrl+F and then F3 you will get the correct search results.
The strange thing is, If you use the option Find uses selected Text the Search with Find Ctrl+F and F3 it works properly at the first time.
This problem occur in selections that contain e.g a dot. Words like addrsin, addrsin1, addrsin2 will be found if you mark addrsin and then search for it.
Link Forum post
http://forums.codeblocks.org/index.php?topic=5842.msg44742;topicseen#new