Community
Participate
Working Groups
The constant is returned from the ISaveablePart2's promptToSaveOnClose() method to indicate to Eclipse that the default prompting mechanism should be used for that part. However, that is respected only if there is a single part involved in the close operation. If there are multiple parts involved and any one of them returns DEFAULT, it is not respected. That basically renders the DEFAULT value not usable since it has different behavior depending on the number of parts being closed and the individual parts have no feedback on how they will be treated when they return this value.
I think this has to do with the timing of the DEFAULT return value ... after we've deleted it from the list of dirty parts. It can be re-ordered. PW
Released a fix into HEAD >20051123 Now, on multiple close any ISaveablePart2 that returns DEFAULT should be allowed to drop through and participate with the other ISaveableParts. PW
on Solaris-Motif I20051213-0010 PW
Paul, does this also double-check the isDirty() flag?
More context for the previous question: see the "saving ISaveablePart2's" thread in the eclipse.platform newsgroup.
So we double-check the flags for ISaveablePart2 ... if you have p1 and p2, p1 is checked, is dirty, and gets saved (and in the operation saves p2), p2 is check and is not dirty and is skipped. But for the ISaveableParts it just a list that's first passed to a dialog for user selection, then passed to a save-loop. I could put another isDirty() check in at either of those ISaveablePart steps. PW
I think adding that check would make sense for the case where multiple parts share the same model, which is pretty common.
Added some extra checks: 1. if an ISaveablePart2 takes action, filter the dirty list so it only contains dirty parts 2. when saving the dirty list, check isDirty() one last time before calling doSave(). Released into HEAD >20051220 PW
Can this be closed?
If it works :) I haven't adopted 3.2M4 yet so I cannot test it just yet but I am sure that you guys have tested it properly and the proposed solution sounded just fine to me.
it looks good PW
verified in RC5 PW
