Code::Blocks Forums
Developer forums (C::B DEVELOPMENT STRICTLY!) => Development => Topic started by: tiwag on May 09, 2006, 02:21:19 pm
-
* FindNext/FindPrevious would wrongly reset the search text if there was selected text in the editor.
seriously, this was a feature and not a bug :)
i added this long ago in order to find selected text and press F3 to search for it, i find it very convenient ..
-
Sorry to say this, but this was a pretty annoying "feature".
If I want to change the search text, I press Ctrl+F not F3 ;)
C::B changing it behind the scenes, without me asking for it, has frustrated me one too many times. And I 'm not the only one...
-
I also am guilty : I also looked at it as not such a nice feature.
It is rather surprising that during your search, just by having something selected, your search suddenly changes. If you want to search on something "new", it is a .... "new search" ;-) -> ctrl+f
-
well i didnt want to annoy someone,
i'm using TextPad Editor since approx. 10 years and i copied the behaviour like Textpad does and found it pretty convenient.
-
LOL, TextPad.
I have a colleague at work who also uses TextPad, and each time I need to do something at his desk, I am swearing about the fact TextPad does not follow the normal (or semi-standard) way of searching. :D
-
It is very annoying as two other issues as well.
When you scroll down and click somewhere and then hit F3 the search starts at the beginning of the page again and NOT where the caret is.
The other is when you open another window and hover mouse over codeblocks, then codeblocks is moved to the front and my just opened window is defocused.
These bugs makes it realy useless.
-
Time to defend Tiwag here, for once.
The original "bug" was something that I perceived as a very useful feature. Although one could object it should be an option because some people may not like it. Personally, I found it very useful, but I am fine with pressing Ctrl-F again, too.
When you scroll down and click somewhere and then hit F3 the search starts at the beginning of the page again and NOT where the caret is.
Not true. If set the caret further down in the document, it certainly starts at that position.
The other is when you open another window and hover mouse over codeblocks, then codeblocks is moved to the front and my just opened window is defocused.
Not true, either. This is a X feature / optional Windows setting. It has nothing to do with Code::Blocks.
-
Not true, either. This is a X feature / optional Windows setting. It has nothing to do with Code::Blocks.
Wait a second, that is only 99% correct. The drag scroll plugin has a function like that too.
But again, you have to enable it... Code::Blocks doesn't do that on its own behalf.
-
When you scroll down and click somewhere and then hit F3 the search starts at the beginning of the page again and NOT where the caret is.
Not true. If set the caret further down in the document, it certainly starts at that position.
It did on mine but somehow with latest compile it doesn't, odd
The other is when you open another window and hover mouse over codeblocks, then codeblocks is moved to the front and my just opened window is defocused.
Not true, either. This is a X feature / optional Windows setting. It has nothing to do with Code::Blocks.
Wait a second, that is only 99% correct. The drag scroll plugin has a function like that too.
But again, you have to enable it... Code::Blocks doesn't do that on its own behalf.
Strange since i don't use the plugin nor didn't i enable it in Windows 2000, yet it does "BringToFront" Code::Blocks.
But this is offtopic and should have its own topic
-
Sorry to say this, but this was a pretty annoying "feature".
If I want to change the search text, I press Ctrl+F not F3 ;)
C::B changing it behind the scenes, without me asking for it, has frustrated me one too many times. And I 'm not the only one...
I really enjoy this feature/bug.
I'd like to work up a patch for this feature/bug that can be turned on/off. Off by default.
Where should the toggle option be placed. Editor config? Find dialog?
What could I name it? Tiwag feature/Mandrav Bug? Find by Marked? Find Marked? Find Selected? Any suggestions?
Would the patch even be considered? I'd rather work on something else if it'd be a futile effort.
thanks
pecan
-
Sorry to say this, but this was a pretty annoying "feature".
If I want to change the search text, I press Ctrl+F not F3 ;)
C::B changing it behind the scenes, without me asking for it, has frustrated me one too many times. And I 'm not the only one...
I really enjoy this feature/bug.
I'd like to work up a patch for this feature/bug that can be turned on/off. Off by default.
Where should the toggle option be placed. Editor config? Find dialog?
What could I name it? Tiwag feature/Mandrav Bug? Find by Marked? Find Marked? Find Selected? Any suggestions?
Would the patch even be considered? I'd rather work on something else if it'd be a futile effort.
thanks
pecan
@Yiannis - is it ok to add this option to svn ?
but i propose to place the checkbox in the Find-Dialog (Ctrl-F)
also i propose to change the checkbox for Auto-wrap-search from
Settings->Editor Dialog to the Find-Dialog Options.
brgs, tiwag
-
the first one, hmmm ;-)
the second one : good idea, then all search setting are in the same spot
-
Yes, put everything into the Find dialog :).
-
Yes, put everything into the Find dialog :).
So happy, I can hardly contain myself !!!
-
Yes, put everything into the Find dialog :).
Patch is #1571
Find dlg wrap and Find uses selected text.
It Moves Find wrap checkbox to Find dlg and implements tiwags "Find uses Selected Text" as an option in Find dlg
-
Patch is #1571
Find dlg wrap and Find uses selected text.
It Moves Find wrap checkbox to Find dlg and implements tiwags "Find uses Selected Text" as an option in Find dlg
changes are in svn rev 3108
thanks to pecan
brgds, tiwag
-
I have 2 suggestions :
1) give a more elaborate explanation of the new 'search with selected" text. Now the user might get the impression that without this option a selection will not be used for a search, it does. The new feature is : "during" a search, the "search" text can change due to a new selection !!! Where in the former case it remains consistent, but when a selection was made before one starts the search that selection is the search text in the popping up find/replace-dialog.
Pff, dunno anymore : you might already see the selection was used, since you got into the dialog and see your selection text in it. Is a bit confusing.
2) find and replace dialog --> the 2 new get functions do the same thing in there if branch and else branch . I would suggest not to branch because this just makes the code unclear and people writing the code might wonder, is it a bug, did I overlook something ...