When adding keybindings to an existing Eclipse RCP application, it is extremelly helpful to get realtime information about which keybinding registered and to what command handlers it is mapped to. Why is that?  Because sometimes the operating system or another widget will consume the keyboard event before it gets to the command framework. Other times there are several handlers bound to the same key causing a conflict.

Enabling Tracing for Keybindigs

Fortunatelly, this information is easy to get, if you enable the right tracing options:

org.eclipse.ui/debug = true
org.eclipse.ui/trace/keyBindings = true
org.eclipse.ui/trace/keyBindings.verbose = true

After that each keystroke will produce some output on the console:

KEYS --- WorkbenchKeyboard.press(potentialKeyStrokes = [CTRL+PAGE_UP, CTRL+])
KEYS --- WorkbenchKeyboard.executeCommand(commandId = 'org.eclipse.riena.navigation.ui.previousSubApplication', parameters = {})

In the above you can see that Ctrl+PageUp is mapped to the ‘previousSubApplication’ command.

Some times there is a conflict – i.e. one keybinding is mapped to two or more ‘active’ command handlers. This looks like this:

BINDINGS --- A conflict occurred for CTRL+SHIFT+W
BINDINGS ---     [Binding(CTRL+SHIFT+W,
	ParameterizedCommand(Command(org.eclipse.ui.file.closeAll,Close All,
		Close all editors,
		Category(org.eclipse.ui.category.file,File,null,true),
		org.eclipse.ui.internal.CloseAllHandler,
		,,true),null),
	org.eclipse.ui.defaultAcceleratorConfiguration,
	org.eclipse.ui.contexts.window,,,system), Binding(CTRL+SHIFT+W,
	ParameterizedCommand(Command(org.eclipse.riena.navigation.ui.closeModuleGroup,Close module group,
		,
		Category(org.eclipse.riena.navigation.ui.swt,Riena Navigation Commands,null,true),
		org.eclipse.riena.internal.navigation.ui.swt.handlers.CloseModuleGroup@39880a,
		,,true),null),
	org.eclipse.ui.defaultAcceleratorConfiguration,
	org.eclipse.ui.contexts.window,,,system)]

What happened here is that Ctrl+Shift+W was already bound to the CloseAllHandler via the ‘file.closeAll’ command. I was not aware of this initially, because it is defined in the org.eclipse.ui plugin. So I accidentally bound another command and handler to Ctrl+Shift+W. With the output I quickly realized what was going on. I ditched my own command and instead made ‘CloseModuleGroup’ a handler for the ‘file.closeAll’ command.

Tags: bindings, eclipse ui, jface, rcp, tips

Were you ever curious how to get those pretty colored labels in your JFace viewers you see all over Eclipse? For example, the blue counter label in the search results view:

Well, I’ll tell you how! Let’s start with famous RCP Mail example:

Let’s look at the current label provider in the RCP Mail example:

class ViewLabelProvider extends LabelProvider {

     public String getText(Object obj) {
          return obj.toString();
     }

     public Image getImage(Object obj) {
          String imageKey = ISharedImages.IMG_OBJ_ELEMENT;
          if (obj instanceof TreeParent)
               imageKey = ISharedImages.IMG_OBJ_FOLDER;
          return PlatformUI.getWorkbench().getSharedImages().getImage(imageKey);
     }
}

Pretty basic right? Well, to get styled labels all we need to do is extend StyledCellLabelProvider (available since Eclipse 3.4):

class ViewLabelProvider extends StyledCellLabelProvider {
     public void update(ViewerCell cell) {
          Object obj = cell.getElement();
          StyledString styledString = new StyledString(obj.toString());

          if(obj instanceof TreeParent) {
               TreeParent parent = (TreeParent) obj;
               styledString.append(" (" +
                    parent.getChildren().length +
                    ")", StyledString.COUNTER_STYLER);
          }

         cell.setText(styledString.toString());
         cell.setStyleRanges(styledString.getStyleRanges());
         cell.setImage(getImage(obj));
         super.update(cell);
     }

     public Image getImage(Object obj) {
          String imageKey = ISharedImages.IMG_OBJ_ELEMENT;
          if (obj instanceof TreeParent)
               imageKey = ISharedImages.IMG_OBJ_FOLDER;
          return PlatformUI.getWorkbench().getSharedImages().getImage(imageKey);
     }
}

If you do that, the RCP Mail example will look like this now:

This just scratches the surface of what is possible with owner draw, styled strings and styled label providers.

Hope this helps and happy styling!

Tags: eclipse, jface, tips

In the last blog entry regarding databinding, we learned how to create a custom observable for a DateTime widget. Starting with Eclipse 3.5 there is a new approach to creating custom observables as described by Matthew Hall in the comments to that post. Which ever way you choose, we will now use the observable to showcase another cool databinding feature: Crossvalidation. Crossvalidation was introduced with Eclipse 3.4 and describes the process of validating one IObservable based on the value or state of another IObservable. A classic example is the input  of a date ranges where the start of the period can not be after the end of the period.

As we can see on the screenshot above, the status message informs us of a violated validation constrain. So, how is such  kind of crosscutting validation achieved? First of we need some kind of model, to hold the start and end value. Next we need the two DateTime widgets and the corresponding DateTimeObservableValue. The observables can than be tied to the bean model, holding the start and end values. In order to create a crosscutting validation for the dates, we introduce a custom PeriodValidator extending a MultiValidator, which is in fact an implementation of a ValidationStatusProvider.The MultiValidator lets us implement a validate() method, returning an IStatus corresponding to our validation results. Since we are implicitly implementing a ValidationStatusProvider, the state of our validation can be bound to any party interested in the validation result. Here is the implementation of the PeriodValidator, comparing the start and end date (ignore the shortcomings of the Date class):

public class PeriodValidator extends MultiValidator {

private final IObservableValue start;
private final IObservableValue end;

public PeriodValidator(final IObservableValue start, final IObservableValue end) {
this.start = start;
this.end = end;
}

@Override
protected IStatus validate() {
Date startDate = (Date) this.start.getValue();
Date endDate = (Date) this.end.getValue();
IStatus status = ValidationStatus.ok();

if ((this.start != null) && (this.end != null)) {
     if (startDate.after(endDate)) {
          status = ValidationStatus.error(”The start date has to be before the end date.”);
     }
}
return status;
}
}

As we can see, there is not much magic going on in the PeriodValidator. Lets have a look at the broader context, in which this MultiValidator is applied. The following code demonstrates the overall setup of the databinding. Note how the validation status (wrapped in an IObservableValue) is obtained from the PeriodValidator and bound to the status Text widget.

private void createDatabinding() {

DateTimeObservableValue startObservable = new DateTimeObservableValue(this.dateTimeStart);
DateTimeObservableValue endObservable = new DateTimeObservableValue(this.dateTimeEnd);
DataBindingContext context = new DataBindingContext();

// bind start and end
UpdateValueStrategy modelToTarget = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
UpdateValueStrategy targetToModel = new UpdateValueStrategy(
UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     startObservable,
     BeansObservables.observeValue(this.period,Period.PROP_START), targetToModel, modelToTarget);

context.bindValue(endObservable,
     BeansObservables.observeValue(this.period, Period.PROP_END), targetToModel, modelToTarget);

// bind status
PeriodValidator periodValidator = new PeriodValidator(startObservable, endObservable);
modelToTarget = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
modelToTarget.setConverter(new Converter(IStatus.class, String.class) {

public Object convert(final Object arg) {

if (arg instanceof IStatus) {
     IStatus status = (IStatus) arg;
     return status.getMessage();
}

return null;
}
});

targetToModel = new UpdateValueStrategy(UpdateValueStrategy.POLICY_UPDATE);
context.bindValue(
     SWTObservables.observeText(this.status),
     periodValidator.getValidationStatus(), targetToModel, modelToTarget);
}

The validation status of the period validator is updated everytime any of the DateTime widgets is changed. In turn the validation message is updated to reflect the validation state.

You can download the the entire project containing the sample snippets here.

Also note that you will need to adjust the elements on the classpath. See the .project file for the required libs.

I hope you found these hints valuable and am looking forward to your comments and suggestions.

Tags: databinding, jface, tips

The introduction of the databinding framework in Eclipse 3.3 is with no doubt one of the most useful tools in the hands of the form developer. The ability to transform and validate user input in such a flexible and reusable way is a great enhancement. But where there is light, there is shadow. Sometimes there is just no IObservable available for your target or model object. This blog entry will demonstrate how easy it can be to create a custom IObservable for a DateTime widget.

The DateTime widget represents one value: a java.util.Date. This Date object is the one we want to get and set on the target (target being the UI widget). Therefore we wrap the DateTime in an IObservableValue by extending the AbstractObservableValue class. Essentially an IObservable* offers methods to get and set data, to determine the type of data and to register listeners to be notified of changes. The following code demonstrates a skeleton implementation of an IObservableValue.

public class DateTimeObservableValue extends AbstractObservableValue {

  private final DateTime dateTime;
  Listener listener = new Listener() { ... };

  public DateTimeObservableValue(final DateTime dateTime) {
    this.dateTime = dateTime;
    this.dateTime.addSelectionListener(this.listener);
  }

  @Override
  protected Object doGetValue() {
    // the utility method creates a Date from the DateTime
    return dateTimeToDate();
  }

  @Override
    protected void doSetValue(final Object value) {
      if (value instanceof Date) {
        // the utility method sets the date on the DateTime
        dateToDateTime((Date) value);
      }
  }

  @Override
    public Object getValueType() {
    return Date.class;
  }

  @Override
    public synchronized void dispose() {
    this.dateTime.removeSelectionListener(this.listener);
    super.dispose();
  }
}

The implementation details are not very special. The getValueType() method has to return the type represented by this IObservableValue (which is the type Date). The do methods set and get the Date value. Since the observable has to propagate changes in the DateTime widget as soon as they ocurre, we attach a listener on the DateTime widget to inform any registered IValueChangeListener of the event. The listener implementation looks like the following:

Listener listener = new Listener() {

  @Override
  public void handleEvent(final Event event) {
    Date newValue = dateTimeToDate();

    if (!newValue.equals(DateTimeObservableValue.this.oldValue)) {
      fireValueChange(Diffs.createValueDiff(DateTimeObservableValue.this.oldValue, newValue));
      DateTimeObservableValue.this.oldValue = newValue;
    }
  }
};

In the DateTime listener we inform any interested IValueChangeListener of our DateTimeObservableValue. In order to avoid unnecessary propagation of update events in the databinding context, we compare the last set Date in the IObservableValue with the new value. Next we create a ValueDiff from our new date value and fire the the value change event. The advantage of listening to the changes in the DateTime widget, is that we are able to fire events which are either invoked by the user changing the DateTime widget or by programmatic changes of the IObservableValues wrapped Date.

You can download the full listing of the observable class here: DateTimeObservableValue.zip

As we can see, it is quite easy to write a custom observable for any kind of widget or datastructure, represented by a single value…  So, how do you embed your data in custom observables? Any obstacles you had to overcome? Problems you faced? Share them with us.

Tags: databinding, datetime, eclipse, jface, observable, tips