Community
Participate
Working Groups
Build: 20020819 0. get store (instance of org.eclipse.core.runtime.Preferences) 1. use store.setValue('key', false); 2. use store.contains('key'); ==> returns false which is a severe bug in my opinion. Reason for the bug is that the key is removed from the store if the value is the same as the default value [ok]. There is a list with default values which is also checked when using contains [ok] but unfortunately the getDefaultBoolean method returns false even if there is no default [bug]. It should either return null or add the key to the default list as soon as returning 'false'
*** Bug 18938 has been marked as a duplicate of this bug. ***
increasing severity since - wrong contains() check can cause other clients to fail - adding a workaround would mean to add a dummy property which I set to something different than the default value.
I agree this should be changed. I think in setValue we should add the value to the default values table if none is present, even if it is equal to the default default value. This behaviour happens for all setValue methods where the value being set is equal to the default default value.
Any idea when this bug gets addressed - 2.1? It causes filter settings being lost (see bug 18938).
The reason that the value isn't set in the table of defaults is because it is equal to the "default default". So the following code pattern does return the correct results: 0. get store (instance of org.eclipse.core.runtime.Preferences) 1. use store.setValue('key', false); 2. use store.getBooleanValue('key'); ==> returns false If you want to have an explicit value for the default, use can use setDefault (String, boolean). If you use this, then the #contains call returns "true". Adding Jeem to CC for comment.
Preferences are a table structure with 2 levels of setting: a default setting and a real setting. This characteristic (which was carried over from the JFace preference store) is thoroughly described in the javadoc, and everything is working as spec'd. Going back to the matter of losing filter settings being lost (bug 18938), I think it see the problem. You have a user setting that is not a user preference, correct?. If the user does something, you want to persistently remember whatever true/false setting the user specifies. If the user does nothing, you don't want to persistently remember anything. If you just use store.setValue(key,b), nothing gets saved when the store is written out for keys where b=false (because false is the default value, and the store doesn't save default values). If you instead use store.setDefaultValue(key,b), nothing ever gets saved when the store is written out (because default values are never saved). Conclusion: You can't use a preference store to persistently save a boolean user setting. Notice that if we were talking about a true user *preference* setting, the specified behavior is generally what you want: save only a 'delta' that captures how this user's preference settings differs from the defaults, without capturing the defaults. With only a slight bit of complication, you can get things to work out by storing a string encoding of a boolean: store.setValue(key, (b ? "T" : "F")); store.contains(key) always returns true and store.getString(key).equals("T") == b provided store.contains(key) If this does indeed solve your original problem, I suggest that we improve the Javadoc for 2.1 (and the preference article?) to document this gotcha and explain the workaround.
Of course I could code the workaround and you could modifiy the Javadoc (though being an API change in my opinion and hence not a good fix for 2.1) but I still can't find any good argument (except implementation details), why "store.contains(key)" should return false after using "store.set(key, value)".
"store.contains(key)" return false after using "store.set(key, value)" when "store.getDefaultBoolean(key) == false" because the user has not set the preference to anything different than the default and there is therefore no need or desire to store an explicit different-from-default value.
>there is therefore no >need or desire to store an explicit different-from-default value. This is OK for me (i.e. how the store is internally implemented) but it is not OK that the store loses the information whether it contains data (be it default or not) for a given key.
This is not an implementation issue --- it is how the preference mechanism is designed to work (i.e., to never store values that are different from the default). Example preference behavior: 1. User is shown preference "x" in unchecked state (the default setting, false) store.getBoolean("x"); 2. User checks the check box store.setValue("x",true); 3. User changes her mind and unchecks the check box store.setValue("x",false); 4. User hits OK The desired behavior is that the store does not contain("x"). When the store is saved, no setting for "x" is written out. In a subsequent session, the user will get the default setting for "x". If the defaullt setting is still "false", they get exactly that. But if the default setting is now "true" (there are several way preference default settings can be changed, including from the comand line), then they get "true".
I don't understand the discussion: The API for contains explicitly says that it considers default values: /** * Returns whether the given property is known to this preference object, * either by having an explicit setting or by having a default * setting. You might change the API/Javadoc for 3.0 but for the current stream it is a bug.
It also says in the class javadoc that explicitly setting to the default value will delete the preference: * ... The existing settings can be changed and new properties * can be set (<code>setValue</code>). If the values specified is the same as * the default value, the explicit setting is deleted from the top layer.
Is I know but isContains also says: * either by having an explicit setting or by having a default setting. ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
The Preferences code (originally copied from JFace preferences) goes to great lengths to not store default values. This behaviour won't be changed. Closing as WONTFIX.
Fixed in the 3.0 stream. See bug 51309.
