Eclipse Community Forums: Graphiti » setBackground(Color color) not immediately affected after a call from an Adapter.notifyChanged()

Home » Modeling » Graphiti » setBackground(Color color) not immediately affected after a call from an Adapter.notifyChanged()

setBackground(Color color) not immediately affected after a call from an Adapter.notifyChanged() [message #1018023]

Tue, 12 March 2013 21:25

Eclipse User

Hi Forum,

I want to change a PE background when user change the property of its business object. I try to achieve it by using adapter to it. It is strange to know that the change is not affected the diagram immediately. It instead affected after another property is changed. This always happens when I try to change a property, the diagram always changed by the previous action and never by the current action.

I think it because the notifyChanged() is always called last. So I wonder how to change the background immediately after the user set some property up. I try to change the background through PropertySection. But it worse. There is always such error when adding an object :

!ENTRY org.eclipse.emf.transaction 4 41 2013-03-13 07:50:01.271
!MESSAGE Read-only transaction rolled back
!SUBENTRY 1 org.eclipse.emf.transaction 4 40 2013-03-13 07:50:01.271
!MESSAGE Transaction aborted due to concurrent write

I desperately need help Sad

Thanks

Emerson

Re: setBackground(Color color) not immediately affected after a call from an Adapter.notifyChanged() [message #1020615 is a reply to message #1018023]

Mon, 18 March 2013 11:14

Eclipse User

Emerson,

this looks like your update feature does not check for the property you
change.

When the EMF domain object changes, EMF notifies Graphiti about this change.
Graphiti checks if there are shapes on the diagram having this object as
business object, in case yes, the according update feature is checked
(updatedNeeded). In case the result is true the update can be done
automatically (depending on editor update settings).

HTH,
Michael

Re: setBackground(Color color) not immediately affected after a call from an Adapter.notifyChanged() [message #1043534 is a reply to message #1020615]

Wed, 17 April 2013 16:52

Eclipse User

Hi Michael,

Probably this is addressed a lot, but I want to ask you one more time, could you please explain what should be done in order Graphiti to able to update the diagram automatically when the EMF model is changed. When I say automatically, I mean without user intervention whatsoever (i.e. by clicking on the update button). In the tutorial it is explained that the shape will get red dotted line around it, and the user need to click on the update button. I want the diagram updated without user interaction at all. The updates are mainly changing names of objects of the model. However, everything will be cached in the updateNeeded function anyway.
In my diagram type provider I override the following functions and set them all to return true:

public boolean isAutoUpdateAtRuntime() {
	return true;
}

/**
 * @since 0.9
 */
public boolean isAutoUpdateAtRuntimeWhenEditorIsSaved() {
	return true;
}

public boolean isAutoUpdateAtStartup() {
	return true;
}

public boolean isAutoUpdateAtReset() {
	return true;
}

However the diagram is not changed automatically even if the diagram is already dirty when the model is changed. In this case a message is shown that the file was edited outside, and the user can choose to accept or discard the most recent changes.

Could you please explain me shortly what am I missing?

Thank you.
Dragan

Re: setBackground(Color color) not immediately affected after a call from an Adapter.notifyChanged() [message #1046877 is a reply to message #1043534]

Mon, 22 April 2013 09:42

Eclipse User

Dragan,

from what you describe returning true on isAutoUpdateAtStartup should be the
right thing in your case.

But it seems that the diagram does not notice that the model has changed
underneath. Graphit triggers the DefaultUpdateDiagramFeature while opening
an editor for checking if anything needs to be marked red or updated
(depending on the setting in isAutoUpdateAtStartup).

The default implementation of that feature simply checks the top level
shapes (resp. their domain objects) for changes, simply by calling their
update features. So I suspect either your changes are not part of a
top-level shape so that the correct features are not called or your features
do not check for the change.

To analyze that you should set a breakpoint in the execute method of that
feature and see what it calles.

Michael

Previous Topic:	hiding context menu entries
Next Topic:	Add for existing Model

Goto Forum:

-=] Back to Top [=-

Current Time: Thu Jul 10 03:05:36 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter