Some Eclipse Foundation services are deprecated, or will be soon. Please ensure you've read this important communication.

Bug 357068

Summary: [implementation] TextViewer returns null for getControl() although this is not spec'd in Viewer's javadoc API
Product: [Eclipse Project] Platform Reporter: Remy Suen <remy.suen>
Component: TextAssignee: Dani Megert <daniel_megert>
Status: VERIFIED FIXED QA Contact:
Severity: normal    
Priority: P3 CC: daniel_megert, markus.kell.r
Version: 3.8   
Target Milestone: 3.8 M3   
Hardware: All   
OS: All   
Whiteboard:

Description Remy Suen CLA 2011-09-08 08:14:20 EDT 
/**
 * Returns the primary control associated with this viewer.
 *
 * @return the SWT control which displays this viewer's content
 */
public abstract Control getControl();

ComboViewer, ListViewer, TableViewer, and TreeViewer all return the control in its getControl() implementation even if the control is disposed. TextViewer does not do this and will return null. Sounds to me like it should a) not return null or b) define that it will in its javadoc.

I noticed this problem while looking at the cause behind bug 357065.
Comment 1 Markus Keller CLA 2011-09-08 08:46:11 EDT 
Has been like this since day 0.

> should a) not return null
+1

> b) define that it will [return null] in its javadoc
That would still violate the inherited contract of Viewer#getControl().

Note that we can't just remove the "fTextWidget= null;", since the class uses a lot of "if (fTextWidget == null ..." tests and ITextViewer#getTextWidget() specifies the current behavior.
Comment 2 Dani Megert CLA 2011-10-11 04:44:53 EDT 
Fixed in master: 1e4b8d7f344d37183189f29a90c66f8970a946cf
Comment 3 Dani Megert CLA 2011-10-26 04:26:43 EDT 
Verified through code inspection.