Community
Participate
Working Groups
R3.1 and newer If ScopedPreferenceStore .removePropertyChangeListener(...) removes the last listener it calls disposePreferenceStoreListener() which disconnects the ScopedPreferenceStore from the eclipse store but does not set preferencesListener to null. Now, when the next client calls addPropertyChangeListener(...) this methods calls initializePreferencesListener() which does nothing because preferencesListener is not null. Therefore the store remains disconnected from the Eclipse preferences and hence property/pref changes are not forwarded to the added listeners. Test Case: 1. open Text editor 2. change the 'Current line highlight' color via Text Editors pref page ==> changed in editor 3. close the editor (this disconnects the scope store forever) 4. open Text editor 5. change the 'Current line highlight' color via Text Editors pref page ==> change does not happen in the editor NOTE: we did not detect this earlier because for non-string preferences this works since ScopedPreferenceStore.setValue(String, <type>) calls firePropertyChangeEvent() for all types (e.g. boolean) except for String typed preferences. Why?
Created attachment 35295 [details] Patch to fix the bug
Thanks for the patch Dani - looks good. To answer your question we don't fire the property changed event for Strings as we can forward the event from the core preferences to our event without modification as the core event is always sent as a String. For the other types we have to ignore the core event as the typing is wrong so we send it ourselves.
Fixed in build >20060228
*** Bug 130807 has been marked as a duplicate of this bug. ***
*** Bug 131454 has been marked as a duplicate of this bug. ***
Verified in 20060328
