| Summary: | [Viewers] Stack overflow if getElements returns the same object as inputElement | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Alex Chapiro <achapiro> |
| Component: | UI | Assignee: | Platform UI Triaged <platform-ui-triaged> |
| Status: | CLOSED DUPLICATE | QA Contact: | Hitesh <hsoliwal> |
| Severity: | trivial | ||
| Priority: | P3 | Keywords: | helpwanted |
| Version: | 3.1.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | Windows XP | ||
| Whiteboard: | |||
This should be documented in StructuredViewer. I don't think it should be a problem for TableViewer, shouldn't it? I guess it should be documented for TreeViewer only. And the question: is it really inevitable limitation, or just the specific of the current implementation? It seems to me that it could be easily overcome. Of course user can also resolve the problem just embedding inputElement in a sort of trivial container. Could be the same implemented in TreeViewer? Hitesh is now responsible for watching bugs in the [Viewers] component area. |
I see this problem in 3.1.1 using TreeViewer. My getElements looks like that: public Object[] getElements(Object inputElement) { if(null != inputElement) return new Object[] {inputElement}; return new Object[0]; } It causes Stack Overflow. It's quite obvious why it happens. I haven't find out anything special in documentation about getElement requirement. So there can be at least two diferent conclusions: a) It's an implementation bug. b) It's not a bug, so it should be documented.