Community
Participate
Working Groups
On the C/C++ IDE platform - when I execute the 'file search' (or control H) after inputing a string - the behaviour is not as expected: - I defined a workset - I input a search string - The first time you input this search string - it finds nothing, and also does NOT save this last search string - The second time you do the same thing - it works fine I must note that this does not happen at all times, but like 80% of the times . Can you fixed it ? It's really anoying :( Thanks Rafi -- Configuration Details -- Product: Eclipse 1.3.1.20100913-1228 (org.eclipse.epp.package.cpp.product) Installed Features: org.eclipse.platform 3.6.1.r361_v20100909-9gF78GrkFqw7GrsZnvz0JWNTeb6fue6896L
Created attachment 181589 [details] my search example
Moved to ticket 328546 (IDE for C++)
What kind of working set is selected? Anything in .log?
*** Bug 328546 has been marked as a duplicate of this bug. ***
Created attachment 181713 [details] My file-search details
I added another screen-shot FYI. I'm new to this, so if you can direct me to the .log I'll try and look it up. Let me detail the repro steps, that might help/hint: - I have a few .c./h-files-tabs open - Execute ctrl-H and select "files-search' and a work set - input a search string - execute the search - if you now do another control-H - everything seems fine - now select another file-tab - do another ctrl-H - the search is NOT maintaning "files-search' tab, but moves to C/C++ search - if you select again "file search" you'll see that the search string is "gone"... it is now - blank - from time to time, after you select another search-type tab, a blank search string is also inserted into the 'files-search' history I'm not sure to if it relates to the exact problem, but I think you should make the last search dialog state - persistant across tabs , and the active search string - persistant PER tab. I hope that helps!
OK, I see what you mean. This is as designed: the most relevant page based on the current selection gets the focus and is initialized with that selection. There are no plans to change that. Note that you can select the previous search from the drop down.
>the most relevant page based on >the current selection gets the focus and is initialized with that selection. Ok, I see. But there is still a difference between the two "search modes/tabs": - in c/c++ mode - you always have the last search string activaly available in it to re-search - in files-search tab - you never preserve it's the last search string , and you always have to re-type it (or get it from the local history) Can you at least fix that ? Thanks
> - in files-search tab - you never preserve it's the last search string , and > you always have to re-type it (or get it from the local history) It works fine here (in combination with JDT not CDT): the 'File Search' string is taken from the editor selection or the previous one is used. Which means of course that if you have the editor active with an empty selection it will feed this into the field. Is that your scenario?
The missing "previous search string" can also be reproduced with Java and File Search: - open a .java editor - Ctrl+H - switch to File Search - enter a search text and perform the search - click into the the Java editor (don't select any text) - Ctrl+H - switch to File Search => empty search text field => expected: File Search tab should be pre-filled with the previous parameters, like when I open it with Ctrl+H while the Search view still has focus.
(In reply to comment #10) > The missing "previous search string" can also be reproduced with Java and File > Search: ... That was a waste of time as I already mentioned this in comment 9 ;-) >=> expected: File Search tab should be pre-filled with the previous parameters, >like when I open it with Ctrl+H while the Search view still has focus. Normally dialogs or wizard don't fall back to the previous input/settings if the selection is empty. However, given we already fall back when the selection is a structured selection, I think we can do that.
> I think we can do that. Thanks ! :-)
Created attachment 181956 [details] Fix
Fixed in HEAD. Available in builds >= N20101101-2000.
Verified in I20101206-1800.
