Bug 14378 - CompareEditorInput never resets dirtyness flag (detailed)
Summary: CompareEditorInput never resets dirtyness flag (detailed)
Status: RESOLVED FIXED
Alias: None
Product: Platform
Classification: Eclipse Project
Component: Compare (show other bugs)
Version: 2.0   Edit
Hardware: PC Windows 2000
: P1 normal (vote)
Target Milestone: ---   Edit
Assignee: Andre Weinand CLA
QA Contact:
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 15406
  Show dependency tree
 
Reported: 2002-04-22 19:31 EDT by Jeff Brown CLA
Modified: 2002-05-15 06:08 EDT (History)
2 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
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