Community
Participate
Working Groups
- start Eclipse - choose Window / Preferences - turn the Welcome Dialog setting off (I'll assume it was on before) - kill Eclipse process from shell - start it again - the Welcome Dialog still comes up This probably applies to all dialog settings. The settings should be saved immediately, since they count as user input which would be lost in the event of a crash. NOTES: RG (5/1/01 3:52:04 PM) I'm certain this functionality was added for the Tech Preview so somewhere along the line it has gotten lost. It is not enough for the preferece dialog to save its store since each of the individual pages may have their own store. I believe the dialog used to get the strore from the pages and do a if (needsSaving) save call. We can no longer do this because the dialog deals with IPreferencePages not PreferencePages. The best solution would be to add a saveStore method to IPreferencePage. In addition we need to add a save method to IPreferenceStore (it already has needsSaving). Although these are breaking API changes I suspect no one will actually be affected since we will implement the methods in PreferencePage and PreferenceStrore and I suspect everyone is using these implementations. Proposed fix (not released) in: PreferenceStore :: org.eclipse.jface.preference 0.101 [rg] 01 PreferencePage :: org.eclipse.jface.preference 0.101 [rg] 01 PreferenceDialog :: org.eclipse.jface.preference 0.101 [rg] 01 IPreferenceStore :: org.eclipse.jface.preference 0.101 [rg] 01 IPreferencePage :: org.eclipse.jface.preference 0.101 [rg] 01 RG (5/4/2001 6:04:26 PM) Transferred these class versions to the new repository jeem (5/4/01 7:53:35 PM) The minimal breaking API changes would be to - clients who implement IPreferencePage directly - clients who implement IPreferenceStore directly This is possible, although it seems more likely that clients are subclassing the standard implementation PreferencePage and PreferenceStore. Since the problem is severe enough, the change should proceed and document as a breaking API change. A client that is currently reimplementing PreferenceDialog.handleSave() to save the preferences (as recommended in old javadoc comment) would not be calling the new method implementation. If all clients should only extend but not reimplement this method, this would be an additional breaking API change and should be documented as such. If, on the other hand, it's fine for a client to reimplement, then this is not a breaking API change. jeem (5/4/01 7:48:45 PM) - Specific comments on version 0.101 [rg] 01 - Comment for PreferencePage.saveStore() should be non-javadoc and refer to IPreferencePage. - Javadoc comment for PreferenceDialog.handleSave() should either (a) allow subclasses to override as before, or (b) allow subclasses to extend only.
PRODUCT VERSION: 101 JDK
Implemented handleSave to save PropertyPages using PropertyStore. Others may subclass to handle other IPropertyPages or IPropertyStores. This handles the common case without requiring any API change.
