Community
Participate
Working Groups
Build ID: Eclipse 3.4 Build id: I20080207-1530 Steps To Reproduce: 1. Open Eclipse 3.4 and above that has projects with many Java classes 2. Open type dialog using Ctrl+Shift+T 3. Use "*" only for the pattern match. -- Nothing happens 4. Use "?" only for the pattern match -- The cache is refreshed with the list. The bug is that wildcard "*" doesn't trigger the search to refresh the cache. More information: This regression is seen from Eclipse 3.3 where in class "org.eclipse.jdt.ui.JavaUI" method "createTypeDialog", the class "org.eclipse.jdt.internal.ui.dialogs.FilteredTypesSelectionDialog" is used instead of "TypeSelectionDialog2".
Noticed similar behaviour with Open Resource dialog as well with the Build : N20081221-2000.
Reassigning to default inbox.
This is not a 'major' issue especially because showing all types is not a practical use case.
This is a regression when compared to Eclipse 3.2. Our produce leverages Eclpipse IDE for its functionality and this breakage in functionality affects the usability of the product. Hence from our product perview, the defect is "Major".
Is it this a test (case) that you apply/run for your product or do you have a concrete report? As said before entering '*' to see all types is not very useful and just because something changed from version a to b doesn't automatically classify it as 'major'.
This bug is reported by our customer while executing one of their test cases. Giving below the exact statement which we got from our Customer representative. "CLIENT BUSINESS IMPACT: 20/20 users are experiencing this issue. Workaround is not acceptable for them. They are requesting a fix." Could you please let us know in which version this will be fixed? Thank you. regards, Sai
A workaround is to enter "**". I am wondering why your users feel that it is important to be able to pick one class from a (potentially very large!) list of classes. The "Open Type" dialog was designed with use cases in mind where users narrow down the list of choices to a very small number by entering a part of the class name. It is not designed to support listing all classes that you could open.
Your workaround works. Thanks. But our customer wants to know when this will be fixed? Could you please let us know for which version of Eclipse this bug is triaged? Thanks.
(In reply to comment #8) > Your workaround works. Thanks. But our customer wants to know when > this will be fixed? Could you please let us know for which version > of Eclipse this bug is triaged? > > Thanks. It would be good if you could explain your use case. At this point, without understanding the situation, we do not plan to change the behaviour. The reason for this is that normally, you enter a prefix of the type you are looking for. For example, entering "Hash" will match HashMap, HashSet etc. Sometimes, users are looking for a type but are not sure about the prefix, they just know a substring. For example, they would enter "*Hash" and get matches like AbstractHashMap, ConcurrentHashMap, HashMap, HashSet etc. In this second case (which we believe is quite common) users start by entering "*". We don't want to show all matches at that time because it would not be what the users want at that time, and it would be a waste of CPU and disk resources to compute if it was not needed. I would go so far as to say that in 3.3, it was wrong to eagerly show all types when users entered "*", and this got fixed in 3.4. I understand that you and your customers would disagree, which is why I am asking why your users would want to see all types (which could be a *very* large list). Maybe they are working on small projects? Or using working sets to narrow down the list of types?
*** Bug 200603 has been marked as a duplicate of this bug. ***
Hitesh is now responsible for watching bugs in the [Viewers] component area.
This bug hasn't had any activity in quite some time. Maybe the problem got resolved, was a duplicate of something else, or became less pressing for some reason - or maybe it's still relevant but just hasn't been looked at yet. If you have further information on the current state of the bug, please add it. The information can be, for example, that the problem still occurs, that you still want the feature, that more information is needed, or that the bug is (for whatever reason) no longer relevant.
