Author Topic: "Find uses Selected Text" broken (Read 20705 times)

Pecan · « **on:** May 28, 2007, 04:32:43 pm »

Somewhere between SVN 3970 and 3975 (nightlies) "Find Uses Selected Text" was broken.

You can nolonger mark text, hit F3 or "find next" using the marked text.

Pecan · « **Reply #1 on:** May 28, 2007, 04:39:19 pm »

Quote from: Pecan on May 28, 2007, 04:32:43 pm

Somewhere between SVN 3970 and 3975 (nightlies) "Find Uses Selected Text" was broken.

You can nolonger mark text, hit F3 or "find next" using the marked text.

Reverting fix 3975 solves this problem.

Code

Index: src/sdk/editormanager.cpp
===================================================================
--- src/sdk/editormanager.cpp	(revision 3987)
+++ src/sdk/editormanager.cpp	(working copy)
@@ -1295,7 +1295,7 @@
     m_LastFindReplaceData->hiddenSearch = dlg->GetHidden();
     m_LastFindReplaceData->initialreplacing = false;
     m_LastFindReplaceData->NewSearch = true;
-    m_LastFindReplaceData->findUsesSelectedText = hasSelection;
+    //-m_LastFindReplaceData->findUsesSelectedText = hasSelection;
     if(control)
     {   // if editor : store the selection start/end
         // only use this in case of !findInFiles and scope==1 (search in selection)

Biplab · « **Reply #2 on:** May 28, 2007, 05:30:45 pm »

Hmm.. my fix broke another part. But it's not broken completely. The bug you've pointed out an be recreated if No search has been made in the editor. Once a search is made, using Ctrl+F, this bug won't show up.

Pecan · « **Reply #3 on:** May 28, 2007, 05:46:06 pm »

I respectfully disagree.

Mark some text. Ctrl-F to make a first find.
Make sure "Find use selected text" box is checked.

Do the find.

Now mark some other text not equal to the first find.
Hit F3.
It finds the first marked text, not the second marked text.

It should have found the second marked text.

One way around this maybe? Check to see if "Find use selected text" box is checked before issuing the 3975 fix.

Biplab · « **Reply #4 on:** May 28, 2007, 05:55:13 pm »

Agreed. I'd revert the change. Thanks for posting it.

Pecan · « **Reply #5 on:** May 28, 2007, 05:57:57 pm »

Quote from: Biplab on May 28, 2007, 05:55:13 pm

Agreed. I'd revert the change. Thanks for posting it.

Why would you revert it? Why not just check for ""Find uses selected text".

Your change must have been good for something. I just dont know what.

You will have to make the change. I cannot.

Biplab · « **Reply #6 on:** May 28, 2007, 06:10:41 pm »

Quote from: Pecan on May 28, 2007, 05:57:57 pm

Your change must have been good for something. I just dont know what.

It was done to fix Bug#10992. Please have a look at it and suggest me any possible fix.

Pecan · « **Reply #7 on:** May 28, 2007, 06:16:31 pm »

Quote from: Biplab on May 28, 2007, 06:10:41 pm

It was done to fix Bug#10992. Please have a look at it and suggest me any possible fix.

Ok, that'll take some time. Berlios is very slow at my end today.

First, in your opinion, did fix3975 fix bug10992 satisfactorily?

Biplab · « **Reply #8 on:** May 28, 2007, 06:19:40 pm »

BTW, I've just checked that reverting the fix will not create that bug.

I'm reverting it. Thanks for the post.

Pecan · « **Reply #9 on:** May 28, 2007, 06:46:44 pm »

Quote from: Biplab on May 28, 2007, 06:19:40 pm

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:

Code

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

Biplab · « **Reply #10 on:** May 28, 2007, 06:55:41 pm »

Quote from: Pecan on May 28, 2007, 06:46:44 pm

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.

I'm also not sure that this is a bug. I reverted it as it works other way.

But we need a solution if it's really a bug.

dmoore · « **Reply #11 on:** May 29, 2007, 08:30:10 pm »

my planned fix for this bug (10992) was to change the default scope to global if a newline was not included in the selection (i.e. if the selection is less than an entire line then default to global scope).

dmoore · « **Reply #12 on:** May 30, 2007, 03:51:00 am »

hi guys:

patch here: http://developer.berlios.de/patch/index.php?func=detailpatch&patch_id=2027&group_id=5358

note that I have removed the disabling of the scope as the user might want to change to the selected scope to find a substring in a very long line of text

cheers
Damien

Pecan · « **Reply #13 on:** May 30, 2007, 04:33:54 pm »

I've applied the patch locally. And have been using it all morning.

It defininitely does the job for both "FindUsesSelectedText" and NON "FindUsesSelectedText".

It seems to please both worlds.

I vote to get biplab to apply it to SVN for further heavy testing.

dmoore · « **Reply #14 on:** May 30, 2007, 04:58:23 pm »

I've just updated the patch (forgot to remove scope disabling in the replace dialog)

Biplab · « **Reply #15 on:** May 31, 2007, 07:12:12 pm »

Sorry for this late reply. I'll test it.

Biplab · « **Reply #16 on:** May 31, 2007, 07:52:07 pm »

The uploaded patch fixes the bug. But it introduces other bug.

1. Duplicate entries of previous search texts are created in the list.

Pecan · « **Reply #17 on:** May 31, 2007, 08:17:38 pm »

Quote from: Biplab on May 31, 2007, 07:52:07 pm

The uploaded patch fixes the bug. But it introduces other bug.

1. Duplicate entries of previous search texts are created in the list.

What list? Are you talking about "find in files" ?

dmoore · « **Reply #18 on:** May 31, 2007, 09:15:18 pm »

Quote from: Pecan on May 31, 2007, 08:17:38 pm

Quote from: Biplab on May 31, 2007, 07:52:07 pm
The uploaded patch fixes the bug. But it introduces other bug.

1. Duplicate entries of previous search texts are created in the list.

What list? Are you talking about "find in files" ?

I assume the list in question is the drop down list of previous searches under "text to search for". I can't replicate.

Pecan · « **Reply #19 on:** May 31, 2007, 09:29:59 pm »

And even if there were duplicates in the dropdown list. It appears it's me that put them there and I'd like to keep it that way.

Biplab · « **Reply #20 on:** June 04, 2007, 06:56:44 pm »

Patch applied in Revision 4055. I've fixed the duplicate entries bugs. It was not due to the patch.

News:

Author Topic: "Find uses Selected Text" broken (Read 20705 times)