| Re: [cdt-dev] Custom Field Editor |
|
The problem I ran into is that we don’t treat the FieldEditors as real field editors. For example, we don’t call doStore to store the result in the preference. And we rely on firing events on every modification
to do the store and accomplish other behavior specific to our editor. It would be a lot easier to maintain and describe if we had JUnit tests to test it. Having said that, I did get it working and an very happy to have this feature. I honestly thought we had it years ago but apparently it’s new to 8.0. Doug. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Belyavsky, Baltasar Doug, Yes, it works, please don’t delete it
J. The ICustomBuildOptionEditor interface is there pretty much only for the purpose of initializing the custom field-editor with some necessary data. So, in addition to implementing this interface, the custom field-editor
must also extend JFace’s FieldEditor class – the FieldEditor class is what takes care of loading and storing the value into the underlying PreferenceStore (which is the build-configuration). The javadoc on the ICustomBuildOptionEditor mentions
that. Here is an example of a simple string editor, which displays as a non-editable textbox (as opposed to a disabled textbox, which can be accomplished through IOptionApplicability): --- public
class ReadOnlyStringOptionEditor
extends StringFieldEditor
implements ICustomBuildOptionEditor {
/* (non-Javadoc) * @see org.eclipse.cdt.managedbuilder.ui.properties.ICustomBuildOptionEditor#init(org.eclipse.cdt.managedbuilder.core.IOption, java.lang.String,
java.lang.String, org.eclipse.swt.widgets.Composite) */
public
boolean init(IOption option, String extraArgument, String preferenceName, Composite parent) {
init(preferenceName, option.getName());
createControl(parent);
return
true; }
/* (non-Javadoc) * @see org.eclipse.cdt.managedbuilder.ui.properties.ICustomBuildOptionEditor#getToolTipSources() */
public Control[] getToolTipSources() {
return
null; }
/* (non-Javadoc) * @see org.eclipse.jface.preference.FieldEditor#doFillIntoGrid(org.eclipse.swt.widgets.Composite, int) */
@Override
protected
void doFillIntoGrid(Composite parent,
int numColumns) {
super.doFillIntoGrid(parent, numColumns);
getTextControl().setEditable(false); } } --- In your doFillIntoGrid() implementation, you can create as complex UI as you want:
Also, see how we inject our tool-chain option-categories directly into the LHS tree. When I have more time, I would like to contribute this to open-source, if there is interest. - Baltasar From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Schaefer, Doug To answer my own question, you need to change the preference value every time the value changes during the edit. The built-in field editors fire off an event to the BuildUI to handle that but it ignores the custom
field editors. So you have to do it yourself. Weird, but works. Doug. From: cdt-dev-bounces@xxxxxxxxxxx [mailto:cdt-dev-bounces@xxxxxxxxxxx]
On Behalf Of Schaefer, Doug Hey gang, Who contributed the ICustomBuildEditor and friends, i.e. custom field editors for build options? Does it actually work? There are no tests for it and no implementations of this interface anywhere I can find. And I can’t see you actually
store the option value on OK. Thanks, Doug. |
