Bug 14378

Summary: CompareEditorInput never resets dirtyness flag (detailed)
Product: [Eclipse Project] Platform Reporter: Jeff Brown <jeff_brown>
Component: CompareAssignee: Andre Weinand <andre_weinand>
Status: RESOLVED FIXED QA Contact:
Severity: normal    
Priority: P1 CC: James_Moody, Kevin_McGuire
Version: 2.0   
Target Milestone: ---   
Hardware: PC   
OS: Windows 2000   
Whiteboard:
Bug Depends on:    
Bug Blocks: 15406    

Description Jeff Brown CLA 2002-04-22 19:31:29 EDT
CompareEditorInput never reverts to being non-dirty unless
explicitly triggered by setDirty().  However client code
cannot reliably determine when the transition from dirty to
non-dirty should take place because they cannot access
the underlying viewers.

For instance, isSaveNeeded() will return 'true' even after
saveChanges(...) has been called.

Problems:
1) The dirty state listener does not check that the property being
   changed is actually dirtyness.  It must verify that the
   property name is CompareEditorInput.DIRTY_STATE.  At the moment
   it will be fooled by any other boolean property.

2) The dirty state listener should keep track of which viewers are
   dirty so that it can determine when the CompareEditorInput instance
   itself should be considered dirty/non-dirty.  The simplest solution
   is to add a viewer to a List when a DIRTY_STATE property change is
   received from it with value true, and to remove it from that List
   when a DIRTY_CHANGE property change is received from it with value false.
   isSaveNeeded() would then return true iff the list was empty.

3) findContentViewer() adds an extra SWT.Dispose event listener
   to the viewer's top-level control each time a viewer is recycled
   (not serious, but wasteful).
Comment 1 Andre Weinand CLA 2002-05-15 06:08:22 EDT
fixed #1, #2, and #3 in > 20020514