Every plug-in has a preference-store. It can be used practically for anything, however it does not take objects that are not serialized in some way. The preference store can only hold low-level data types, such as numbers or Strings, and not generic objects.
In this example, I've created a simple action that just tests to see if some preference is set or is null. I also create a preference page that can be accessed via the Window->Preferences-> menu items. The preference page uses any number of SWT controlls you desire, so long as you keep control of saving then as preferences when the user is done and clicks apply or ok.
Preference Stores demand Strings as keys for all preferences. They can store a default value for any preference, as well as a current value. The values can be of type boolean, double, float, int, long, or String. This data is usually held in the .metadata directory of the current workspace.
According to the javadoc:
* A property change event is reported whenever a preferences current * value actually changes (whether through setValue, * setToDefault, or other unspecified means). Note, however, * that manipulating default values (with setDefault) * does not cause such events to be reported.
The IPreferenceStore interface contains the following groups of methods. The character sequence TYPE will denote any of the words boolean, int, double, float, long, String.
We'll start just by looking at our action. It's an extremely simple action, and the only completed method is the following one:
public void run(IAction action) {
// Here we'll just get our preference store and see if it
// contains a preference by that name.
IPreferenceStore store = Example7PreferenceStorePlugin
.getDefault().getPreferenceStore();
boolean contains = store.contains(PreferencePage1.TARGET_PREFIX + "0");
System.out.println("Does store contain one target? " + contains );
if( contains ) {
String s = store.getString(PreferencePage1.TARGET_PREFIX + "0");
PreferencePage1.NameUriPair pair = new PreferencePage1.NameUriPair(s);
System.out.println("name: " + pair.getName() + ", uri: " + pair.getUri());
}
}Basically, we just get the string from the preferencestore, if it exists, and make a NameUriPair out of it. Then just display the pair's parts. If the preference has been set in that workspace and is currently in the preference store, it will display it.
The extension point to extend is org.eclipse.ui.preferencePages and only takes a page element underneath it. The page element only requires a name, id, and class. So it's a pretty simple extension point to use. From there, the rest of the preference page is handled by your preference page class file and it's interaction with the plug-in's preference store.
<extension
id="Example7PreferenceStore.preferencePage"
name="Example7PreferenceStore.preferencePage"
point="org.eclipse.ui.preferencePages">
<page
class="example7PreferenceStore.preferences.PreferencePage1"
id="Example7PreferenceStore.page1"
name="Example7PreferenceStore.page1"/>
</extension>
The preference page that I created extends the PreferencePage class, which an abstract class containing only one abstract method: abstract Control createContents(Composite parent); You will also need to override the performOk method, which is called from the superclass whenever either the apply or the ok buttons are pressed. This is the method that should save the preferences selected by the user in the preference store.
Our createContents method should return a composite that we want to go in the main content area of the preference page. Ideally, you should create any widgets using parent as the parent control, and then at the end of the method, return your main composite to the superclass.
The superclass uses a grid-layout, but if you return your new composite, it will make sure it fills the entire area in the middle of the preference page, both horizontally and vertically. If you don't return your composite, any controls you add to the parent control will be added in the superclass's gridlayout fashion. In this example, I've created one form layout composite, with sub-elements, and returned it to the superclass.
For loading the preferences, I just take each preference beginning with a prefix and ending with an integer, until I find a null element. Then I insert each of those into their respective tables in the gui. For saving them, I do the same but serialize them.
The file chooser list (top list) stores everything as a String, so no serialization is necessary to put it in the preference store. The Target list (bottom) stores elements as a NameUriPair object, and they must be serialized with a newline as the separator to be inserted into the preference store.
To test the example, run the plug-in in a runtime environment. From there, right click on any file in any prokect in the runtime environment. (If one does not exist, you can create one. For my test, I created a file named test.file). Right click on this element to see it's context menu and select our action named Our Test Action.
If we look at our console in our development instance of eclipse (not the runtime environment), we'll see that the preference is not set or does not exist. If we then go to Window->Preferences and select the tab for our plug-in's preferences, and fill in each table with some different data, apply the changes and click ok, we can try the action again.
Trying the action again, if we added a target element to the bottom list in the preferences, we should see that the preference is indeed set now.