Hello Ed,
I agree with your point on the properties view. It's purpose is
justified for requirements not needing GUI validation, however, to
implement on the spot GUI validation, the Properties view is not
sufficient. For this reason, I believe an effort in 4.0 should be
reserved towards the adjustment of the JET templates to generate an EMF
editor using eclipse forms.
Here are the main changes I made. I feel that some of them could be
improvements made for 4.0 whenever possible.
* I created a composite panel for every node in the tree. I modified
the ObjectDetailsPage and removed the SampleSection inner class. I
replaced it with a DetailsSection class responsible to create the
panels and update them in function of the "Object input" variable
private void detailsPageSwitch(final Object input)
{
sampleSectionHolder = new DetailSection(toolkit, input,
adapterFactoryItemDelegator, adapterFactoryLabelProvider,
mform.getMessageManager(), this);
ScrolledPropertiesBlock.setDetailsPage(this);
sampleSectionHolder.createSection(input);
}
public void update()
{
detailsSection.setText(adapterFactoryItemDelegator.getText(input));
detailsSection.layout();
ScrolledPropertiesBlock.setDetailsPage(this);
sampleSectionHolder.updateSection(input);
}
With the detailsPageSwitch(), I pass the message manager of the
managed form (mform) SrolledPropertiesBlock class to every panel.
As such, the panels now have control on the message manager and
can add / remove errors depending whether the user types in a
widget or switches from the one node to another.
_
_
* There is one "problem" with radio buttons (A = "true" and B =
"false" initially) attached to boolean attributes in EMF.
and
As radio buttons are mutually exclusive, setting B, unsets A
automatically. This will register as two actions in the EMF's
command stack (B = "true", then A = "false"). If the user presses
undo once, the B radio button will be "false" leaving A radio
button "false" as well. The user must execute a second undo
action to revert to the initial state.
To prevent this from happening, I had to "hack" the
EditingDomainActionBarContributor class located in
org.eclipse.emf.edit.ui.action so I can call cutom Undo and Redo
actions.
I created the following and put all custom code in my plugin:
public class CustomEditingDomainActionBarContributor extends
MultiPageEditorActionBarContributor implements IMenuListener,
IPropertyListener {
[....]
protected CustomUndoAction customUndoAction;
protected CustomRedoAction customRedoAction;
[....]
}
Custom Undo/Redo actions call themselves recursively if they
detect that variables reserved for a group of mutually exclusive
radio buttons are all set to false
public class CustomRedoAction extends RedoAction {
@Override
public void run()
{
super.run();
MyEditor.updateFromRedoUndo();
Command mostRecentCommand =
domain.getCommandStack().getMostRecentCommand();
if (mostRecentCommand instanceof SetCommand)
{
SetCommand mostRecentSetCommand = (SetCommand)
mostRecentCommand;
EObject owner = mostRecentSetCommand.getOwner();
/***********************************************************************************************************
* MyNodeImpl OWNER
**********************************************************************************************************/
if (owner instanceof MyNodeImpl)
{
if (!((MyNodeImpl) owner).isReadOnly() &&
!((MyNodeImpl) owner).isReadWrite() && !((MyNodeImpl)
owner).isWriteOnly())
run(); // RUN AGAIN TO SET THE RADIO BUTTON
THAT WAS DESELECTED
[....]
_
_
* The eclipse forms panels (with every widget bound to the model)
was not updated during an Undo or Redo action. I added both
actions a MyEditor.updateFromRedoUndo(); statement that calls the
editor to refresh the current selected panel in the Scrolled
properties block:
public static void updateFromRedoUndo()
{
try
{
if
(scrolledPropertiesBlock.treeViewer.getTree().getSelection().length
!= 0)
{
scrolledPropertiesBlock.getObjectDetailsPage().update();
}
}
catch (Exception e)
{
}
}_
_
This update mechanism for the eclipse forms does not exist on the
EMF example found on the net.
_
_
_
_
* I added error and warning status variables for every node in the
model. This is really custom work, however with the usage of the
eclispe forms' message manager, this complements very well the
user experience.
Data can have errors or warnings in the panels, so I changed the
item providers for every node to display the icons in an
error/warning state. Whenever we use validation on such panels,
the nodes in the tree must reflect these same error states for
later correction (say the errors exist but the user chooses to
save/closes his file and chooses fix the errors later during the
day; he must then know where the errors are...).
I also made the parent nodes aware if their children have errors
or warnings so they can be propagated to the root node. This makes
the errors easier to search if the nodes are collapsed. How the
error/warning flags are initialized on the faulty node is custom
implementation, however, the error propagation to the parent nodes
is performed in the model's implementation classes. Only the
latter mechanism could be accomodated in a future version of EMF.
See pictures below for a better understanding. I had to hide some
information as the product is still under development.
1.
2.
3.
4.
5.
6.No more errors / warnings in the tree
Thanks,
Mircea
Ed Merks wrote:
Tom,
All that command stuff came long after we'd already done the EMF.Edit
support. It's impossible to keep up with the Jone's when there are
dozens of them and only two or three of us. Maybe an Eclipse 4.0
effort would allow us to throw away some of the cruft and focus on
supporting only the latests and greatest patterns.
I'd be happy to provide hooks for whatever solution works well for
this type of scenario. I hope we can find at least a bit of time this
release to look at how to support forms and exploit data binding. I'm
kind of sick and tired of the limitations of the crummy properties
view (which doesn't even work for RAP).
Tom Schindl wrote:
Ed Merks schrieb:
Mircea,
Gosh, I don't have a lot of experience with this type of thing. I
hope someone else has some clue, because I won't even know where to
begin. Maybe Tom will read this and have an idea...
Tom has read it :-) I'm not really skilled when it comes to all those
key-binding thingies.
But the following could work. If your TextWidget receives focus I'd
try to reset the copy/cut/paste actions to their original counter parts:
widget.addFocusListener( new FocusListener() {
IAction emfcutaction =
actionBars.getGlobalActionHandler(ActionFactory.CUT.getId());
IAction emfcopyaction =
actionBars.getGlobalActionHandler(ActionFactory.COPY.getId());
IAction emfpasteaction =
actionBars.getGlobalActionHandler(ActionFactory.PASTE.getId());
IAction standardCut = ActionFactory.CUT.create(....);
IAction standardCopy = ActionFactory.COPY.create(....);
IAction standardPaste = ActionFactory.PASTE.create(....);
public void focusLost(FocusEvent e) {
actionbars.setGlobalActionHandler(ActionFactory.CUT.getId(),emfcutaction);
actionbars.setGlobalActionHandler(ActionFactory.COPY.getId(),emfcopyaction);
actionbars.setGlobalActionHandler(ActionFactory.PASTE.getId(),emfpasteaction);
actionbars.updateActionBars();
}
public void focusGained(FocusEvent e) {
actionbars.setGlobalActionHandler(ActionFactory.CUT.getId(),standardCut);
actionbars.setGlobalActionHandler(ActionFactory.COPY.getId(),standardCopy);
actionbars.setGlobalActionHandler(ActionFactory.PASTE.getId(),standardPaste);
actionbars.updateActionBars();
}
});
If this works it would be great if the
EditingDomainActionBarContributor would provide a possibility to
restore the actions.
Another possible solution that comes to my mind is usage of the
commands framework. I don't know if COPY/CUT/PASTE are handled by
commands (but Paul knows so I've added eclipse.platform to the CC
list :-).
Tom
M. Luchian wrote:
Hello,
The EditingDomainActionBarContributor.java class defined in the EMF
plugins overrides the Windows CUT/COPY/PASTE actions' keyboard
shortcuts (CTRL-X, CTRL-C, CTRL-V) with EMF's own.
This is correct as long as the actions are performed on the tree.
However, I implemented an editor based on eclipse forms, with text
widgets (Windows native) handling the COPY CUT PASTE actions with a
right click of a mouse. As the mouse actions work fine and interact
with the windows' clipboard, pressing the keyboard shortcuts for
the same actions in the text widgets will call the actions reserved
by EMF .. This is problematic as the CTRL-X, CTRL-C, CTRL-V
shortcuts are overridden with the EMF copy, cut, paste actions for
the entire editor.
Is there a possible way to register the actions for the editor's
tree only? (See picture)
I have a CustomEditingDomainActionBarContributor.java replacing a
few small things from the original
EditingDomainActionBarContributor.java class, but I don't want to
manage the registering / unregistering the copy, cut and paste
actions when the tree is in focus or not.
Any help appreciated
Thanks,
Mircea