Obschon sich das Verhalten von 'IPreferenceStore' zur Verfügung gestellt durch AbstractUIPlugin#getPreferenceStore()
, nicht geändert hat, haben wir die Spezifikation von 'IPreferenceStore' aktualisiert, um das Verhalten, das wir zur Verfügung gestellt haben, explizit zu definieren.
Eingabe von PropertyChangeEvents
Alle Änderungsereignisse für Eigenschaften von einem 'IPreferenceStore' müssen einen alten und einen neuen Wert desselben Typs haben, der mit dem setValue-Aufruf, der sie generiert hat, konsistent ist.
Wenn Sie zum Beispiel IPreferenceStore#setValue(String name, long
value)
aufrufen, sind die Werte in 'PropertyChangeEvent', das von dieser Methode generiert wird, beide vom Typ java.lang.Long
.
putValue
Aufrufe von #putValue
generieren kein PropertyChangedEvent
.
Aufrufe der verschiedenen #setValue
-Methoden machen dies jedoch.
Beziehung zwischen der OSGI-Benutzervorgabe und einem IPreferenceStore
Der IPreferenceStore, der durch AbstractUIPlugin#getPreferenceStore()
zur Verfügung gestellt wird, ist ein Exemplar von ScopedPreferenceStore
, das org.osgi.service.prefs.Preferences
als Back-End verwendet. org.osgi.service.prefs.Preferences
verbreitet Änderungsereignisse nur als Zeichenfolgen.
ScopedPreferenceStore
packt die durch IPreferenceStore#setValue(String name, String value)
generierten OSGI-Ereignisse und eines seiner eigenen PropertyChangeEvents
und leitet die Ereignisse an seine Listener-Funktionen weiter. Für die anderen Implementierungen von IPreferenceStore#setValue
erstellt ScopedPreferenceStore
seine eigenen Ereignisse des korrekten Typs und verbreitet nicht die Ereignisse der OSGI-Benutzervorgaben.
Listener-Funktionen für eine ScopedPreferenceStore
sollten sowohl für eingegeben Werte als auch für Zeichenfolgewerte vorbereitet sein, da es immer noch möglich ist, das ein Ereignis über die OSGI-Benutzervorgaben (zum Beispiel während des Imports einer Benutzervorgabe) erhalten wird.
OSGI-Ereignisse sind immer vom Typ java.lang.String.
Es ist immer möglich gewesen, eine Null-org.eclipse.swt.widgets.Shell von der vorhandenen IWorkbenchWindows in Eclipse SDK zu erhalten. Wir definieren nun explizit die Bedingungen, unter denen dies eintrifft, nämlich dann, wenn die Shell nicht erstellt worden ist oder wenn das IWorkbenchWindow geschlossen worden ist.