Eclipse Community Forums: GEF » Caching Edit Parts

Home » Eclipse Projects » GEF » Caching Edit Parts

Mon, 10 February 2003 09:20

Eclipse User

Originally posted by: g.wagenknecht.intershop.de

Hi!

Is it allowed to cache edit parts? I have some strange behavior with our
model and the edit parts.

I have an adapter manager which tracks creation of EditParts. Whenever an
edit part is created for a model object, it registers this edit part.

When an editor is closed, the EditPart#deactivate is called but never
EditPart#removeNotify. A while back Eric told me that #removeNotify is the
replacement for #dispose.

I use #removeNotify to tell the adapter manager that the EditPart for the
specified model element is no longer used. Thus, the adapter manager will
create a new one next time an EditPart is requested. But this never happends
because #removeNotify never get called.

In EditPart#activate and EditPart#deactivate I register/unregister the
EditPart as event listener to the model. When an editor is closed
EditPart#deactive is executed. Next time the editor is opend EditPart#active
is executed. But now the editor is broken. I can't do anything in it. It
displays the figures for the model EditParts but no connections. I can't
select anything in it. As soon as I click into the editor the following
exception is thrown.

org.eclipse.swt.SWTException: Widget is disposed
at org.eclipse.swt.SWT.error(SWT.java:2231)
at org.eclipse.swt.SWT.error(SWT.java:2161)
at org.eclipse.swt.widgets.Widget.error(Widget.java:381)
at org.eclipse.swt.widgets.Control.getDisplay(Control.java:731)
at org.eclipse.swt.widgets.Widget.isValidThread(Widget.java:589 )
at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:311)
at org.eclipse.swt.widgets.Scrollable.getVerticalBar(Scrollable .java:176)
at org.eclipse.draw2d.FigureCanvas$2.propertyChange(FigureCanva s.java:57)
at
java.beans.PropertyChangeSupport.firePropertyChange(Property ChangeSupport.ja
va:252)
at
java.beans.PropertyChangeSupport.firePropertyChange(Property ChangeSupport.ja
va:278)
at
org.eclipse.draw2d.DefaultRangeModel.firePropertyChange(Defa ultRangeModel.ja
va:49)
at
org.eclipse.draw2d.DefaultRangeModel.setMinimum(DefaultRange Model.java:108)
at
org.eclipse.draw2d.FreeformViewport.readjustScrollBars(Freef ormViewport.java
:62)
at org.eclipse.draw2d.Viewport.validate(Viewport.java:305)
at org.eclipse.draw2d.Figure.validate(Figure.java:1559)
at
org.eclipse.draw2d.DeferredUpdateManager.validateFigures(Def erredUpdateManag
er.java:160)
at
org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager
..java:90)
at
org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateMan
ager.java:37)
at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 1)
at
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:94)
at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:1669)
at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :1414)
at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1467)
at org.eclipse.ui.internal.Workbench.run(Workbench.java:1450)
at
org.eclipse.core.internal.boot.InternalBootLoader.run(Intern alBootLoader.jav
a:845)
at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39
)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl
..java:25)
at java.lang.reflect.Method.invoke(Method.java:324)
at org.eclipse.core.launcher.Main.basicRun(Main.java:247)
at org.eclipse.core.launcher.Main.run(Main.java:703)
at org.eclipse.core.launcher.Main.main(Main.java:539)

Any ideas?

Cu, Gunnar

Re: Caching Edit Parts [message #63944 is a reply to message #63849]

Mon, 10 February 2003 11:01

Eclipse User

Originally posted by: none.us.ibm.com

I cannot think of a situation where caching the parts would make sense.
Judging by the stacktrace, it looks like one of your EditParts from the
previous Editor is still listening to the model, and trying to layout its
Figures and FigureCanvas.

"Gunnar Wagenknecht" <g.wagenknecht@intershop.de> wrote in message
news:b28b10$2qj$1@rogue.oti.com...
> Hi!
>
> Is it allowed to cache edit parts? I have some strange behavior with our
> model and the edit parts.
>
> I have an adapter manager which tracks creation of EditParts. Whenever an
> edit part is created for a model object, it registers this edit part.
>
> When an editor is closed, the EditPart#deactivate is called but never
> EditPart#removeNotify. A while back Eric told me that #removeNotify is the
> replacement for #dispose.
>
> I use #removeNotify to tell the adapter manager that the EditPart for the
> specified model element is no longer used. Thus, the adapter manager will
> create a new one next time an EditPart is requested. But this never
happends
> because #removeNotify never get called.
>
> In EditPart#activate and EditPart#deactivate I register/unregister the
> EditPart as event listener to the model. When an editor is closed
> EditPart#deactive is executed. Next time the editor is opend
EditPart#active
> is executed. But now the editor is broken. I can't do anything in it. It
> displays the figures for the model EditParts but no connections. I can't
> select anything in it. As soon as I click into the editor the following
> exception is thrown.
>
> org.eclipse.swt.SWTException: Widget is disposed
> at org.eclipse.swt.SWT.error(SWT.java:2231)
> at org.eclipse.swt.SWT.error(SWT.java:2161)
> at org.eclipse.swt.widgets.Widget.error(Widget.java:381)
> at org.eclipse.swt.widgets.Control.getDisplay(Control.java:731)
> at org.eclipse.swt.widgets.Widget.isValidThread(Widget.java:589 )
> at org.eclipse.swt.widgets.Widget.checkWidget(Widget.java:311)
> at org.eclipse.swt.widgets.Scrollable.getVerticalBar(Scrollable .java:176)
> at org.eclipse.draw2d.FigureCanvas$2.propertyChange(FigureCanva s.java:57)
> at
>
java.beans.PropertyChangeSupport.firePropertyChange(Property ChangeSupport.ja
> va:252)
> at
>
java.beans.PropertyChangeSupport.firePropertyChange(Property ChangeSupport.ja
> va:278)
> at
>
org.eclipse.draw2d.DefaultRangeModel.firePropertyChange(Defa ultRangeModel.ja
> va:49)
> at
>
org.eclipse.draw2d.DefaultRangeModel.setMinimum(DefaultRange Model.java:108)
> at
>
org.eclipse.draw2d.FreeformViewport.readjustScrollBars(Freef ormViewport.java
> :62)
> at org.eclipse.draw2d.Viewport.validate(Viewport.java:305)
> at org.eclipse.draw2d.Figure.validate(Figure.java:1559)
> at
>
org.eclipse.draw2d.DeferredUpdateManager.validateFigures(Def erredUpdateManag
> er.java:160)
> at
>
org.eclipse.draw2d.DeferredUpdateManager.performUpdate(Defer redUpdateManager
> .java:90)
> at
>
org.eclipse.draw2d.DeferredUpdateManager$UpdateRequest.run(D eferredUpdateMan
> ager.java:37)
> at org.eclipse.swt.widgets.RunnableLock.run(RunnableLock.java:3 1)
> at
>
org.eclipse.swt.widgets.Synchronizer.runAsyncMessages(Synchr onizer.java:94)
> at org.eclipse.swt.widgets.Display.runAsyncMessages(Display.jav a:1669)
> at org.eclipse.swt.widgets.Display.readAndDispatch(Display.java :1414)
> at org.eclipse.ui.internal.Workbench.runEventLoop(Workbench.jav a:1467)
> at org.eclipse.ui.internal.Workbench.run(Workbench.java:1450)
> at
>
org.eclipse.core.internal.boot.InternalBootLoader.run(Intern alBootLoader.jav
> a:845)
> at org.eclipse.core.boot.BootLoader.run(BootLoader.java:462)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at
>
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAcce ssorImpl.java:39
> )
> at
>
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMe thodAccessorImpl
> .java:25)
> at java.lang.reflect.Method.invoke(Method.java:324)
> at org.eclipse.core.launcher.Main.basicRun(Main.java:247)
> at org.eclipse.core.launcher.Main.run(Main.java:703)
> at org.eclipse.core.launcher.Main.main(Main.java:539)
>
> Any ideas?
>
> Cu, Gunnar
>
>

Re: Caching Edit Parts [message #63988 is a reply to message #63944]

Mon, 10 February 2003 12:16

Eclipse User

Originally posted by: g.wagenknecht.planet-wagenknecht.de

Hi!

"Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
news:b28gv5$862$1@rogue.oti.com...
> I cannot think of a situation where caching the parts would make sense.

MyModel#getAdapter(EditPart.class)

Anyway, why is EditPart#removeNotify not called when the editor is closed?
As told to me that method should be a replacement for EditPart#dispose which
was called when the editor was closed. If that method would be called, the
cached edit parts would be thrown away and new edit parts created if an
editor is reopend.

IMHO it also doesn't make sence IMHO to have:
EditPart#activate and EditPart#addNotify
EditPart#deactivate and EditPart#removeNotify
if an edit part could not be reused when a new editor is opend.

> Judging by the stacktrace, it looks like one of your EditParts from the
> previous Editor is still listening to the model, and trying to layout its
> Figures and FigureCanvas.

The exception occurs on every click I do into an reopend editor.

Cu, Gunnar

Re: Caching Edit Parts [message #64055 is a reply to message #63988]

Mon, 10 February 2003 13:56

Eclipse User

Originally posted by: none.us.ibm.com

"Gunnar Wagenknecht" <g.wagenknecht@planet-wagenknecht.de> wrote in message
news:b28l5l$c7f$1@rogue.oti.com...
> Hi!
>
> "Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
> news:b28gv5$862$1@rogue.oti.com...
> > I cannot think of a situation where caching the parts would make sense.
>
> MyModel#getAdapter(EditPart.class)
>
> Anyway, why is EditPart#removeNotify not called when the editor is closed?
> As told to me that method should be a replacement for EditPart#dispose
which
> was called when the editor was closed. If that method would be called, the

Check again. That method was never called during shutdown, which is one of
the reasons that dispose() was a bad name and was changed. The method is
*only* called when an EditPart is removed from its parent and thus its
EditPartViewer. For performance reasons, there is no reason to remove
EditParts from their parents when the entire viewer is getting thrown out.

Use activate()/deactivate() for things that have scope that is outside the
viewer, such as listening to the model. Use addNotify()/removeNotify() for
stuff that is EditPart<->Viewer related.

> cached edit parts would be thrown away and new edit parts created if an
> editor is reopend.
>
> IMHO it also doesn't make sence IMHO to have:
> EditPart#activate and EditPart#addNotify
> EditPart#deactivate and EditPart#removeNotify
> if an edit part could not be reused when a new editor is opend.
>
> > Judging by the stacktrace, it looks like one of your EditParts from the
> > previous Editor is still listening to the model, and trying to layout
its
> > Figures and FigureCanvas.
>
>
> The exception occurs on every click I do into an reopend editor.
>
> Cu, Gunnar
>
>
>
>
>

Re: Caching Edit Parts [message #64167 is a reply to message #64055]

Tue, 11 February 2003 02:10

Eclipse User

Originally posted by: g.wagenknecht.intershop.de

"Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
news:b28r65$hgk$1@rogue.oti.com...

> Use activate()/deactivate() for things that have scope that is outside the
> viewer, such as listening to the model. Use addNotify()/removeNotify()
for
> stuff that is EditPart<->Viewer related.

So when should the EditPart's figure be disposed? In deactivate()?

IMHO EditParts are nothing more then adapters for the model - like property
source or workbench adapters. All these objects are reusable. IMHO the
problem with an reused EditPart is that it already has its children and
connection and anything else. But the GEF needs to track changes. It doesn't
evaluate an EditPart on "startup". It only recognizes changes via
add/removeChild() and add/remove[Source|Target]Connection().

Cu, Gunnar

Re: Caching Edit Parts [message #64230 is a reply to message #64167]

Tue, 11 February 2003 10:47

Eclipse User

Originally posted by: none.us.ibm.com

"Gunnar Wagenknecht" <g.wagenknecht@intershop.de> wrote in message
news:b2a66j$9hg$1@rogue.oti.com...
> "Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
> news:b28r65$hgk$1@rogue.oti.com...
>
> > Use activate()/deactivate() for things that have scope that is outside
the
> > viewer, such as listening to the model. Use addNotify()/removeNotify()
> for
> > stuff that is EditPart<->Viewer related.
>
> So when should the EditPart's figure be disposed? In deactivate()?

There is no dispose method on Figure. What do you mean?

> IMHO EditParts are nothing more then adapters for the model - like
property
> source or workbench adapters. All these objects are reusable. IMHO the

It's not quite the same. EditParts have their own state (specifically UI
state) separate from the model, such as selection or what type of feedback
is currently being displayed. And, since the same model object may be
viewed multiple times and in multiple editors, you need EditPart instances
for each occurrence.

> problem with an reused EditPart is that it already has its children and
> connection and anything else.

And most importantly UI state.

You cannot have a single EditPart per model object in the same way that you
cannot have a single TreeViewer providing content for mulitple SWT Trees.

> But the GEF needs to track changes. It doesn't
> evaluate an EditPart on "startup". It only recognizes changes via
> add/removeChild() and add/remove[Source|Target]Connection().
>
> Cu, Gunnar
>
>
>

Re: Caching Edit Parts [message #64254 is a reply to message #64230]

Tue, 11 February 2003 11:22

Eclipse User

Originally posted by: g.wagenknecht.intershop.de

Hi!

"Randy Hudson" <none@us.ibm.com> schrieb im Newsbeitrag
news:b2b4gj$2cp$1@rogue.oti.com...

> You cannot have a single EditPart per model object in the same way that
you
> cannot have a single TreeViewer providing content for mulitple SWT Trees.

I noticed several side effects so I removed the caching. It works ok now
except the scrolling :(

Cu, Gunnar

Previous Topic:	dragging outside area
Next Topic:	draw2d TextExample.java

Goto Forum:

-=] Back to Top [=-

Current Time: Sat May 31 06:20:08 EDT 2025

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter