Community
Participate
Working Groups
FilteredItemsSelectionDialog#getElementName does not allow null values but we have had cases where subclasses have returned null and we should protect against this. See Bug 178969 for details of the use cases right now.
Created attachment 61807 [details] Patch fixes this problem
Created attachment 63092 [details] Proposition of changes Inside patch i used method TableViewer#testFindItem(Object element) to check if element exists inside Table. I see it's hack for test but it's one public method for check it. The other solution is new implementation of TableViewer. The other fix proposition for this bug is implemenation of ViewerFilter which check if elements exist in TableViewer and do the same as attached patch.
This patch belongs to Bug 175507
Created attachment 63153 [details] Patch refreshed to head Patch protect against null names.
Patch released for build >20050424
Is FilteredItemsSelectionDialog#getElementName(Object) now allowed to return null or not? If it is allowed, then you should update the Javadoc (see also bug 178969 comment 10). If it is not allowed, then you should not protect call sites in FilteredItemsSelectionDialog (to avoid hiding bugs in client code).
Yes FilteredItemsSelectionDialog#getElementName(Object) allowed to return null, but in that case we lose camelCase sorting functionality and duplicate checking (all elements are mark as duplicate and will be decorated by container name). Right that should be described. I open new bug for javadoc corrections.