Home » Archived » IMP » Preference change listener
| Preference change listener [message #23373] |
Fri, 01 August 2008 14:20  |
Eclipse User |
|
|
|
Originally posted by: crapo.research.ge.com
I've just spend some time trying to figure out how to put a change
listener on a Preferences value sent on a field on the project preferences
ConfigurationTab. Nothing that I tried worked. I found a bug report from
2004 requesting an addChangeEventListener for a FieldEditor. (It has a set
event listener method.)
Is there an example? Am I missing something in the documentation? In
"Using IMP to Develop Preference Services and Pages" it says that the
class org.eclipse.uide.preferences.IMPPreferencesUtilities is useful for
"Preference-change listeners for different types of preference and field
(for monitoring changes in the preferences model)". That class doesn't
seem to exist. The field "fPrefUtils" of type
"org.eclipse.imp.prefreences.PreferencesUtilities" in the project's
PreferencesConfigurationTab class doesn't seem to offer any methods
helpful in adding a listener.
My need is simple. When a certain preference changes I need to do a clean
rebuild.
|
|
|
| Re: Preference change listener [message #23460 is a reply to message #23373] |
Fri, 01 August 2008 16:19  |
| Eclipse User |
|
|
|
Originally posted by: crapo.research.ge.com
I guess the change listener would have to be at the ProjectTab level. I
added fields to my ProjectTab and where the comment says "// Add property
change listeners" I added a call:
addProjectPreferenceChangeListeners(rc, "Reasoner",
rc.getRadioBoxControl().getParent());
where rc is a RadioGroupFieldEditor. I get no complaints when this line
executes, but I also don't see that I've added a listener--at least not
one that I have access to where I can put my code to rebuild...
|
|
|
| Re: Preference change listener [message #24039 is a reply to message #23460] |
Mon, 25 August 2008 19:34 |
 Stan Sutton
Messages: 121
Registered: July 2009 |
Senior Member |
|
|
Andy,
Apologies for the delayed response on this. The documentation for
preferences is out of date in some parts--it's on the list of
documentation to be updated when we can get to it. In any case, the
parts related to the programming or generation of IMP preference pages
and tabs are most out of date; the parts that describe the IMP
preferences model and its relationship to the underlying Eclipse
preferences model are still generally relevant.
The methods in org.eclipse.imp.preferences.PreferencesUtilities are more
for IMP developers than for IMP IDE developers. But your question
suggests that we should perhaps have a set of utilities for IDE developers.
You probably actually don't want a listener on the IMP preference page
or on any individual tab. What you probably want is listeners on the
underlying Eclipse preferences service that the IMP preference service
uses to store preference values. (Note that preferences can be changed
without going through the preference pages, so listeners on pages won't
necessarily pick up all preference changes.)
Without going into too many of the details, Eclipse service stores
preference values in "nodes"; by default you get one "node" for each of
the preference scopes: default, eclipse installation, eclipse
workspace, and eclipse project. (OK--to be somewhat more precise,
there's one for each installation, one for each workspace, and one for
each project, but at any given point you have one available at each level.)
Each node is an implementation of
org.eclipse.core.runtime.preferences.IEclipsePreferences
An IEclipsePreferences allows you to add and remove node-change
listeners and preference-change listeners. The node-change listeners
have to do with adding and removing nodes from the preferences model,
which you should not be concerned with. The preference-change listeners
will pick up changes in specific preference values for the specific
node. This is what you need.
The IMP preferences service has a method
public IEclipsePreferences getPreferences(String level)
that will give you the node for each level (default, configuration,
etc.). You can add preference-change listeners to these nodes.
Managing the changes, i.e., knowing when you want to rebuild your
project, is just a little tricky. The issue is knowing when a change to
a node actually affects the preference value that is in force for the
project. (For example, changes to higher levels may not matter if the
preference is overridden at a lower level. To address this, you might
just test the applicable value of the preference for your project every
time the value changes. Store the old value whenever you test. If the
new value is different, then you've had an effective change.
When I say "test the applicable value", I mean just query the IMP
preference service for the value that applies at that point--that should
get the applicable value regardless of the level at which it's actually set.
(Aside: I've glossed over some of the complexity in the Eclipse
preferences service. At each scope the nodes are, in effect, divided
into different namespaces, so that at each level you can store separate
sets of preferences for different applications (for example). The IMP
preferences service takes advantage of this to sort out the preferences
for different languages. When you work with the IMP preferences service
for your language, IMP takes care of getting the preference nodes that
are used for your language. You should be able to ignore this wrinkle
when working with the IMP preferences service--that's part of what the
service provides--but you may see some signs of it if you start poking
into code related to the Eclipse preference nodes. But you should be
able to work with preferences in your own language, and set up listeners
on the preference nodes for your language, without worrying about any of
this.)
I hope this helps. This is another area where we should offer some
programming tips or put an entry into the FAQ.
Regards,
Stan
Andrew Crapo wrote:
> I guess the change listener would have to be at the ProjectTab level. I
> added fields to my ProjectTab and where the comment says "// Add
> property change listeners" I added a call:
>
> addProjectPreferenceChangeListeners(rc, "Reasoner",
> rc.getRadioBoxControl().getParent());
>
> where rc is a RadioGroupFieldEditor. I get no complaints when this line
> executes, but I also don't see that I've added a listener--at least not
> one that I have access to where I can put my code to rebuild...
>
|
|
| |
| Re: Preference change listener [message #573139 is a reply to message #23460] |
Mon, 25 August 2008 19:34 |
Stan Sutton
Messages: 121
Registered: July 2009 |
Senior Member |
|
|
Andy,
Apologies for the delayed response on this. The documentation for
preferences is out of date in some parts--it's on the list of
documentation to be updated when we can get to it. In any case, the
parts related to the programming or generation of IMP preference pages
and tabs are most out of date; the parts that describe the IMP
preferences model and its relationship to the underlying Eclipse
preferences model are still generally relevant.
The methods in org.eclipse.imp.preferences.PreferencesUtilities are more
for IMP developers than for IMP IDE developers. But your question
suggests that we should perhaps have a set of utilities for IDE developers.
You probably actually don't want a listener on the IMP preference page
or on any individual tab. What you probably want is listeners on the
underlying Eclipse preferences service that the IMP preference service
uses to store preference values. (Note that preferences can be changed
without going through the preference pages, so listeners on pages won't
necessarily pick up all preference changes.)
Without going into too many of the details, Eclipse service stores
preference values in "nodes"; by default you get one "node" for each of
the preference scopes: default, eclipse installation, eclipse
workspace, and eclipse project. (OK--to be somewhat more precise,
there's one for each installation, one for each workspace, and one for
each project, but at any given point you have one available at each level.)
Each node is an implementation of
org.eclipse.core.runtime.preferences.IEclipsePreferences
An IEclipsePreferences allows you to add and remove node-change
listeners and preference-change listeners. The node-change listeners
have to do with adding and removing nodes from the preferences model,
which you should not be concerned with. The preference-change listeners
will pick up changes in specific preference values for the specific
node. This is what you need.
The IMP preferences service has a method
public IEclipsePreferences getPreferences(String level)
that will give you the node for each level (default, configuration,
etc.). You can add preference-change listeners to these nodes.
Managing the changes, i.e., knowing when you want to rebuild your
project, is just a little tricky. The issue is knowing when a change to
a node actually affects the preference value that is in force for the
project. (For example, changes to higher levels may not matter if the
preference is overridden at a lower level. To address this, you might
just test the applicable value of the preference for your project every
time the value changes. Store the old value whenever you test. If the
new value is different, then you've had an effective change.
When I say "test the applicable value", I mean just query the IMP
preference service for the value that applies at that point--that should
get the applicable value regardless of the level at which it's actually set.
(Aside: I've glossed over some of the complexity in the Eclipse
preferences service. At each scope the nodes are, in effect, divided
into different namespaces, so that at each level you can store separate
sets of preferences for different applications (for example). The IMP
preferences service takes advantage of this to sort out the preferences
for different languages. When you work with the IMP preferences service
for your language, IMP takes care of getting the preference nodes that
are used for your language. You should be able to ignore this wrinkle
when working with the IMP preferences service--that's part of what the
service provides--but you may see some signs of it if you start poking
into code related to the Eclipse preference nodes. But you should be
able to work with preferences in your own language, and set up listeners
on the preference nodes for your language, without worrying about any of
this.)
I hope this helps. This is another area where we should offer some
programming tips or put an entry into the FAQ.
Regards,
Stan
Andrew Crapo wrote:
> I guess the change listener would have to be at the ProjectTab level. I
> added fields to my ProjectTab and where the comment says "// Add
> property change listeners" I added a call:
>
> addProjectPreferenceChangeListeners(rc, "Reasoner",
> rc.getRadioBoxControl().getParent());
>
> where rc is a RadioGroupFieldEditor. I get no complaints when this line
> executes, but I also don't see that I've added a listener--at least not
> one that I have access to where I can put my code to rebuild...
>
|
|
|
Goto Forum:
Current Time: Wed Apr 24 19:16:09 GMT 2024
Powered by FUDForum. Page generated in 0.03460 seconds |
] 
Search
Help
Register
Login
Home
