| Removing a Model Element causes Invalid thread access [message #533186] |
Wed, 12 May 2010 10:08  |
Chris Messages: 44 Registered: April 2010 |
Member |
|
|
Hi,
currently I'm developing an UML class editor for Eclipse. When the user drags a Java-File (ICompilationUnit) onto the drawing area, the contained Java type (IType) it is rendered as UML type box. Now my problem is the following:
- When the .java-file is deleted, the diagram's EditPart (implementing the IElementChangedListener interface), informs the diagram's model about this deletion via method call.
- Then the model looks if it containes any UML boxes of types contained in that deleted file.
- If any such a model of a UML box exists, it removes the model of the box from itself and informs the diagram's EditPart about the deletion via method call using a PropertyChangeSupport delegate.
- The diagram's EditPart then calls refreshChildren(); which ultimately results in an "Invalid thread access" in
org.eclipse.draw2d.DeferredUpdateManager.sendUpdateRequest(D eferredUpdateManager.java:243).
Is it not permissible to let EditPart and ModelClass interact in the way I let them via method calls? How can I avoid the "Invalid thread access"?
Any insight you can give would be highly appreciated.
Regards,
Chris
|
|
|
| Re: Removing a Model Element causes Invalid thread access [message #533493 is a reply to message #533186] |
Fri, 14 May 2010 05:15   |
Vijay Raj Messages: 604 Registered: July 2009 |
Senior Member |
|
|
replace your refreshChildren method code like this
refreshChildren()
{
Display.getDefault().syncExec(new runnable()
{
//Method code
}
}
This is not required usually because the delete happens from ui only, but in your case the java file file has been deleted and that notification is non UI thread.
---------------------
why, mr. Anderson, why, why do you persist?
Because I Choose To.
Regards,
Vijay
|
|
|
| Re: Removing a Model Element causes Invalid thread access [message #533794 is a reply to message #533493] |
Mon, 17 May 2010 02:33  |
Chris Messages: 44 Registered: April 2010 |
Member |
|
|
Hi,
I wanted to thank you, your tip set me on the right track for the final solution of the problem.
With a bit of modification, your tip worked just fine. I did not override the refreshChildren method in my EditPart, so I wrapped its only occurence in propertyChange. That helped a bit. I still got the exception, but the MVC got all updated correctly and the editor would no longer freeze.
The next step was a good long look at the stack trace. Looking at it, I decided, the best place to catch the exception would be in the firePropertyChange method. So I created a nested class FirePropertyChangeRunnable implementing the Runnable interface and accepting the three arguments of firePropertyChange in the constructor.
Now, any time my model would call firePropertyChange , it calls
Display.getDefault().syncExec(new FirePropertyChangeRunnable(CHILD_REMOVED_PROPERTY, null, child));
instead.
So thanks again, you made my day 
Regards,
Chris
|
|
|
Powered by
FUDForum. Page generated in 0.01998 seconds