Summary: | CompareEditor.setInput() does not notify ISaveablesLifecycleListener | ||||||
---|---|---|---|---|---|---|---|
Product: | [Eclipse Project] Platform | Reporter: | Boris Bokowski <bokowski> | ||||
Component: | Compare | Assignee: | Andre Weinand <andre_weinand> | ||||
Status: | VERIFIED FIXED | QA Contact: | |||||
Severity: | critical | ||||||
Priority: | P1 | CC: | andre_weinand, Michael.Valenta, Mike_Wilson | ||||
Version: | 3.2 | ||||||
Target Milestone: | 3.2 RC4 | ||||||
Hardware: | All | ||||||
OS: | All | ||||||
Whiteboard: | |||||||
Attachments: |
|
Description
Boris Bokowski
2006-05-10 12:44:21 EDT
I would like to see this fixed for RC4. Patch to follow. Created attachment 40991 [details]
patch against org.eclipse.compare
McQ, Michael, Andre, do you approve? +1 +1 I have some questions about the patch: 1) Can the site ever return a null life cycle listener. If it vcan, a null check is needed. 2) The lifecycle change for the new input is only fired if there was an old input. Is this the intent (i.e. is it guaranteed that the workbench will query for the saveables in the case where the oldInput was null)? (In reply to comment #6) > 1) Can the site ever return a null life cycle listener. If it vcan, a null > check is needed. No, null will not be returned, this "service" is always there. > 2) The lifecycle change for the new input is only fired if there was an old > input. Is this the intent (i.e. is it guaranteed that the workbench will query > for the saveables in the case where the oldInput was null)? Because init() calls setInput(), this check is required. The workbench will query for the saveables after calling init(). Unless the input may be set to null during the lifetime of the compare editor, there will always be an old input when a compare editor instance is reused. +1 Looks like this has enough +1s without me but +1 anyway. patch reviewed, applied, and verified for RC4 Verified using I20060512-0010. |