Develop Reference

Eclipse RCP view will not update when editor data is modified

I'm attempting to do something that seems like it should be quite common, so I'm surprised I'm having a hard time finding a solution.
I have a simple Eclipse RCP application. It consists of a view, containing a treeViewer that displays elements of an xml file hierarchically. The other side is an editor, which contains various fields such as textboxes, etc, for displaying and also modifying the xml values. The treeviewer displays icons alongside the element name, and what I'm trying to do is change the icon to a "modified" version of the icon whenever a change is made in the editor - signifying that a value of that element has been changed. This is very similar to how Eclipse, when integrated with subversion, shows that a file has been modified from the base revision in the Package Explorer.
I'll try to just show the parts of the code relevant to this specific issue and hope I don't leave anything out. This is the editor class:
public class XmlEditor extends EditorPart
{
protected boolean dirty = false;
public void setDirty(boolean value)
{
dirty = value;
firePropertyChange(PROP_DIRTY);
}
}
and this is the view with the tree:
public class TreeView extends ViewPart implements IPropertyChangeListener {
public void createPartControl(Composite parent) {
treeViewer = new TreeViewer(parent, SWT.BORDER | SWT.MULTI | SWT.V_SCROLL);
getSite().setSelectionProvider(treeViewer);
treeViewer.setLabelProvider(new TreeObjLabelProvider());
treeViewer.setContentProvider(new TreeObjContentProvider());
PlatformUI.getWorkbench().getWorkingSetManager().addPropertyChangeListener(this);
}
public void propertyChange(PropertyChangeEvent event) {
if (event.getProperty().equals(IWorkbenchPartConstants.PROP_DIRTY)) {
treeViewer.refresh();
}
}
}
In this scenario, TreeView::propertyChange() is not getting called, even though firePropertyChange() is getting fired. Any ideas why? I'm also open to any other ideas that don't involve PropertyChangeListener, it just seemed like this would be the easiest way at the time. Thank you.

Here's how I ended up solving the problem:
Changed TreeView to implement IPropertyListener instead of IPropertyChangeListener
Implemented the propertyChanged() method to perform a treeViewer.refresh()
In the XmlEditor::createPartControl() method I got a reference to the Treeview part and then added it to the property listeners like so:
TreeView treeView = (TreeView) getSite().getPage().findView(TreeView.ID);
addPropertyListener(treeView);
Now, TreeView::propertyChanged() gets called after firePropertyChanged(), just like I needed. It took quite a bit of experimentation to learn the difference between IPropertyListener and IPropertyChangeListener, addPropertyListener() and addPartPropertyListener().
Thanks to nitind for giving me a new perspective, and for showing me about Decorators, which is definitely the right way to go as opposed to changing the tree icon to a modified version.

You fired a property change in the editor part, which is unrelated to the working set manager. Nothing you've done connects the view to the editor. If you want the two to talk to each other, write them to talk to each other, or at least create and react to events from making the modifications you describe.
I'm also pretty certain that's not how SVN shows that a file has been modified.
SVN is probably supplying a Decorator: http://eclipse.org/articles/Article-Decorators/decorators.html

Add this bunch of code in your create part control this will may be help you
ResourcesPlugin.getWorkspace().addResourceChangeListener(new IResourceChangeListener() {
#Override
public void resourceChanged(IResourceChangeEvent event) {
treeViewer.refresh();
}
});

Skip missing editor files when starting workbench

The standard behavior of the Eclipse workbench is to preserve the set of open files between invocations, and attempt to reopen those same files on restart. If any of the files is missing, then a placeholder editor appears showing an error message about the missing file. We'd like to change the behavior of our Eclipse RCP application to just silently skip any missing files instead.
We're already writing our own IApplication, WorkbenchAdvisor, etc; these classes get to inject various behaviors into the platform, but I haven't found a way to accomplish these through these classes. How could we implement the desired behavior?

The way I've handled this is actually in the editor being created: Override setInput to examine the IEditorInput being passed in for validity by calling editorInput.exists() (which, in the case of a FileEditorInput, checks to see if the file exists) or if you're using custom editor inputs, any other validation you need.
If the editorInput fails validation, then close the editor asynchronously (Eclipse doesn't like it when an editor closes before it finishes opening):
public void close () {
Display.getDefault().asyncExec(new Runnable () {
public void run () {
getSite().getPage().closeEditor(YourEditorClass.this, false);
}
});
}
An alternative way of handling this issue is to just disable reopening the editors on startup - see In Eclipse, how to close the open files(editors) when exiting without auto-load in next startup

Eclipse: Ctrl+Shift+Right is incorrect

Consider this simple class:
package net.zomis.test;
public class Test {
public Test() {
}
public void registerSomething(String key) {
}
}
When I have the cursor placed right before registerSomething and pressing CtrlShift→, I'm used to Eclipse only selecting register at first. But now, it selects the entire registerSomething text, when I press it again it selects the entire method (from public void to }), when I press it again it selects the entire class, and the last time the entire file is selected. The exactly same thing happens if I press CtrlShift←.
Also, when I simply click the End key, I get an option to choose: Line End or Text End.
What has gone wrong in my settings for this to happen? Where can I find these keybindings?
If it matters, I have this workspace within my Dropbox-folder to synchronize it between my PC and Mac.

Turns our that the fact that I had the workspace in my Dropbox folder matters a lot. Note to everybody else: Do not share your workspace between computers. How I solved this is the following:
Create a new workspace on each computer
In the computer-specific workspace, import projects from your shared Dropbox/other folder
I noticed that when having a shared workspace on the computers, the Mac somehow changed the key-bindings to the Mac-version, which made them not work on the PC. The correct Ctrl+Shift+→ key-binding on Mac is Alt+Shift+→.
So by using a separate workspace on each computer, I can use that computer's specific key-bindings, without mixing them up.

Open the preferences dialog from the Main Menu: Window->Preferences.
In the dialog, open General->Keys. You'll see a table of keybindings, with a field with type filter text. In that field, type: Ctrl+Shift+Right, and you'll narrow the table down to this key.
The behavior that you expect - only register is selected with the first keypress - is the behavior that I see when using Ctrl+Shift+Right, and the keybinding for me is: Select Next Word.
There is a Restore Command button that should reset this binding if it has been changed.

Take action on NetBean's editor's window closing

We are using NetBeans Platform 7.0.1, and have implemented support for a new language using this (now “obsolete”) tutorial.
Since all our contents are stored in a database, and not on files, we open them like this:
FileSystem fs = FileUtil.createMemoryFileSystem();
FileObject fo = fs.getRoot().createData(fileName, fileExtension);
… write contents from database to `fo` ….
DataObject data = MyMultiDataObject.find(fo);
EditorCookie.Observable cookie = data.getCookie(EditorCookie.Observable.class);
cookie.open();
… forces undock of editor window …
And, in our layer.xml, have added a custom button to Save that sends the content back to the database.
However, when the user closes the file (by either closing the tab or the window), we haven’t figured a way of saving it.
Adding a PropertyChangeListener to the Cookie and watching for PROP_DOCUMENT (and newValue() == null) seems to do the trick for when the window is closed. But how does one get the return value from the confirmation window (I’m referring to when the file is closed after changes, the message File xxx.xxx is modified. Save it?)?

Well, it seems we've been approaching the problem in the wrong way.
Since we are opening the file in-memory, it was suggested in the netbeans-dev list that we should listen for changes in the file itself, by using
fo.addFileChangeListener(new CustomFileChangeListener());
public class CustomFileChangeListener implements FileChangeListener {
#Override
public void fileChanged(FileEvent fe) {
... file has been saved in the editor, sync with database ...
}
}
And keep it synchronized that way, taking advantage of the built-in NetBeans Platform "save" functionality.

Adding figures using contextual menu - Eclipse GEF

All,
I am creating a palette less eclipse plugin where am adding figures to the custom editor through the contextual menu, but am not finding a way to do it. Can anyone please guide me as to how to go about adding figures to editor dynamically through context menu i.e. adding actions/commands.
Since Eclipse GEF plugin development finds so less examples to look at, I am adding my solution so others find it useful. This code helps to render a node to the editor.
Source code for Action class to render figures to the editor:
public class AddNodeAction extends EditorPartAction
{
public static final String ADD_NODE = "ADDNODE";
public AddNodeAction(IEditorPart editor) {
super(editor);
setText("Add a Node");
setId(ADD_NODE); // Important to set ID
}
public void run()
{
<ParentModelClass> parent= (<ParentModelClass>)getEditorPart().getAdapter(<ParentModelClass>.class);
if (parent== null)
return;
CommandStack command = (CommandStack)getEditorPart().getAdapter(CommandStack.class);
if (command != null)
{
CompoundCommand totalCmd = new CompoundCommand();
<ChildModelToRenderFigureCommand>cmd = new <ChildModelToRenderFigureCommand>(parent);
cmd.setParent(parent);
<ChildModelClass> newNode = new <ChildModelClass>();
cmd.setNode(newNode);
cmd.setLocation(getLocation()); // Any location you wish to set to
totalCmd.add(cmd);
command.execute(totalCmd);
}
}
#Override
protected boolean calculateEnabled()
{
return true;
}
}

I think you need multiple different things here. Please remember that GEF would like you to have proper MVC pattern, where you have your own model, Figures as View and EditParts as controllers.
From the top of my head I would say that you need at least these things:
CreateCommand
contains all model level modifications that you need to
perform to add your new data to your
data model (undoable and transactional)
CreateAction
makes that CreateCommand instance, initializes it with current selection and executes that command in editdomain
ContextMenuProvider
Provides that CreateAction to context menu
If you happen to be using GMF the canonical mechanism will generate the editparts for you automatically when you make the model modifications inside a command, but if you are not using GMF, you must make sure that your own models and editparts are handling and refreshing the new item adding properly.
EDIT:
Ok, here is some code suggestion with playing around with requests.
public void run() {
// Fetch viewer from editor part (might not work, if not, try some other way)
EditPartViewer viewer = (EditPartViewer) part.getAdapter(EditPartViewer.class);
// get Target EditPart that is under the mouse
EditPart targetEditPart = viewer.findObjectAt(getLocation());
// If nothing under mouse, set root item as target (just playing safe)
if(targetEditPart == null)
targetEditPart = viewer.getContents();
// Make and initialize create request with proper information
CreateRequest createReq = new CreateRequest();
createReq.setLocation(getLocation());
createReq.setFactory(new OwnFactoryImplementation());
// Ask from target editpart command for this request
Command command = targetEditPart.getCommand(createReq);
// If command is ok, and it can be executed, go and execute it on commandstack
if(command != null && command.canExecute()) {
viewer.getEditDomain().getCommandStack().execute(command);
}
}
Now what happens is that editpart will be requested for creation, so the action itself doesn't know how the command works, what makes it objective agaist the command.
So to make things work, you need to install new EditPolicy to your EditPart. EditPolicies can be installed on EditParts createDefaultEditPolicies() function. This EditPolicy must react and return command when there is CreateRequest. This way any child can provide own kind of command for creating children for itself.
Here is a good image how it works (controller is EditPart):
Please ask if I can help you some more. I know that this looks bit more complex, but this makes your own life much more easier, and after you have done that, you actually understand Command-Request Pattern quite well, and it can be reused in many different places.