Summary: | Default extension in text search is often wrong (1GHFMPL) | ||
---|---|---|---|
Product: | [Eclipse Project] JDT | Reporter: | Nick Edgar <n.a.edgar> |
Component: | UI | Assignee: | Dani Megert <daniel_megert> |
Status: | RESOLVED WONTFIX | QA Contact: | |
Severity: | normal | ||
Priority: | P4 | CC: | erich_gamma |
Version: | 2.0 | ||
Target Milestone: | --- | ||
Hardware: | All | ||
OS: | Windows 2000 | ||
Whiteboard: |
Description
Nick Edgar
2001-10-10 23:05:29 EDT
moved to 'active' PRODUCT VERSION: 0.9 so the proposal is to leave as is? Yes. Proposal is to leave as is because all search stuff is input centric. We also try to set the fields (Search Expression, Search For, Limit To) from the current selection. In my opinion the 80% case is that if you select something and then press search, that you give it a context and that you expect the corresponding search page being in front and filled accordingly. Using previous values in the text search page would not fix the described problem since the wrong page is in front in the first place. Suggest to close. Feels like to do better we'd need to know that entries in .properties files are often referenced by .java files. Feel free to close if you don't think using previous settings is better. Visited it again. Leave as is. Opening the text search for .properties makes sense. What about a checkbox on the search page or a preference: [x] Switch to page based on selection I'd prefer not to introduce another option. I can live with the current behaviour. Can close PR. That's ok for me. |