Home » Eclipse Projects » GEF » A question about setContents()
| A question about setContents() [message #87933] |
Wed, 23 July 2003 08:56  |
Eclipse User |
|
|
|
Originally posted by: wangning.db.pku.edu.cn
I override an EditPart's performRequest to handle double-click event. When
user double-clicks the EditPart, I setContents() the corresponding model
so that the graphical editor switches to inside view of that
model(EditPart). As suggested by Hudson, after setContents(), all
EditParts are recreated. However, in my editor, the original EditPart is
detached from RootEditPart but still active, and Exception raises when
some of its methods are called. Is it right way to achieve my goal? And
how can I avoid such exceptions? Thanks!
|
|
| |
| Re: A question about setContents() [message #88010 is a reply to message #87963] |
Wed, 23 July 2003 09:40  |
| Eclipse User |
|
|
|
Originally posted by: wangning.db.pku.edu.cn
Randy Hudson wrote:
> Please try adding a breakpoint and finding out why this happens.
> In setContents, the root editparts are written such that the deactivate the
> previous contents. What did yo umean by still active?
//////////////////////////////////////////////////////////// ///////////////////
in performRequest(), I wrote:
getViewer().setRootEditPart(new ScalableFreeformRootEditPart());
getViewer().setContents(m);
should I setRootEditPart before setContents()? It will raise exceptions if
I comment that line.
//////////////////////////////////////////////////////////// ///////////////////
After double-clicking, the graphical editor changed to inside view
successfully. However, when clicking the background, such exception raises:
//////////////////////////////////////////////////////////// ///////////////////
Unhandled exception caught in event loop.
Reason:
IWAG0003E Figure is not a child of this parent
//////////////////////////////////////////////////////////// ///////////////////
The Stack looks like:
FreeformLayer(Figure).remove(IFigure) line: 1037
FreeformLayer.remove(IFigure) line: 53
ResizableEditPolicy(SelectionHandlesEditPolicy).removeSelect ionHandles()
line: 98
ResizableEditPolicy(SelectionHandlesEditPolicy).hideSelectio n() line: 87
ResizableEditPolicy(SelectionEditPolicy).setSelectedState(in t) line: 131
SelectionEditPolicy$1.selectedStateChanged(EditPart) line: 54
SequenceEditPart(AbstractEditPart).fireSelectionChanged() line: 413
SequenceEditPart(AbstractEditPart).setSelected(int) line: 958
SequenceEditPart.setSelected(int) line: 65
ScrollingGraphicalViewer(AbstractEditPartViewer).setSelectio n(ISelection)
line: 442
MarqueeDragTracker(MarqueeSelectionTool).performMarqueeSelec t() line: 265
MarqueeDragTracker(MarqueeSelectionTool).handleButtonUp(int) line: 201
MarqueeDragTracker(AbstractTool).mouseUp(MouseEvent, EditPartViewer) line:
760
SelectionTool.mouseUp(MouseEvent, EditPartViewer) line: 398
DefaultEditDomain(EditDomain).mouseUp(MouseEvent, EditPartViewer) line: 229
DomainEventDispatcher.dispatchMouseReleased(MouseEvent) line: 250
LightweightSystem$EventHandler.mouseUp(MouseEvent) line: 443
TypedListener.handleEvent(Event) line: 132
EventTable.sendEvent(Event) line: 81
FigureCanvas(Widget).sendEvent(Event) line: 840
Display.runDeferredEvents() line: 1838
Display.readAndDispatch() line: 1545
Workbench.runEventLoop(Window$IExceptionHandler) line: 1402
Workbench.run(Object) line: 1385
InternalBootLoader.run(String, URL, String, String[], Runnable) line: 845
BootLoader.run(String, URL, String, String[], Runnable) line: 461
NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not
available [native method]
NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39
DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25
Method.invoke(Object, Object[]) line: 324
Main.basicRun(String[]) line: 291
Main.run(String[]) line: 747
Main.main(String[]) line: 583
And the breakpoint is:
//////////////////////////////////////////////////////////// ///////////////////
public void remove(IFigure figure) {
if ((figure.getParent() != this) || !children.contains(figure))
(***) throw new IllegalArgumentException(
Draw2dMessages.ERR_Figure_Remove_Exception_IllegalArgument);
figure.removeNotify();
if (layoutManager != null)
layoutManager.remove(figure);
// The updates in the UpdateManager *have* to be
// done asynchronously, else will result in
// incorrect dirty region corrections.
figure.erase();
figure.setParent(null);
children.remove(figure);
revalidate();
}
//////////////////////////////////////////////////////////// ///////////////////
For a model (Say AModel), after setContents(m), a new EditPart (say
BEditPart) is created instead of the original AEditPart, to act as a root.
I just wonder why the methods of AEditPart are still called though it is
obviously DEACTIVATE?
That looks tedious. Thank you very much for your help!
> "Wang Ning" <wangning@db.pku.edu.cn> wrote in message
> news:bfm0l4$tac$1@eclipse.org...
> > I override an EditPart's performRequest to handle double-click event. When
> > user double-clicks the EditPart, I setContents() the corresponding model
> > so that the graphical editor switches to inside view of that
> > model(EditPart). As suggested by Hudson, after setContents(), all
> > EditParts are recreated. However, in my editor, the original EditPart is
> > detached from RootEditPart but still active, and Exception raises when
> > some of its methods are called. Is it right way to achieve my goal? And
> > how can I avoid such exceptions? Thanks!
> >
|
|
| | | |
| Re: A question about setContents() [message #88188 is a reply to message #88069] |
Thu, 24 July 2003 10:47 |
| Eclipse User |
|
|
|
Originally posted by: wangning.db.pku.edu.cn
Randy Hudson wrote:
How to open a bugzilla? I cannot connect to the server bug.eclipse....
I think I know where the problem is. I mean, I guess I know. When the user
double-clicks, a MouseDown event is dispatched and the SelectionTool is
activated on the EditPart, say OldEditPart. Then the OldEditPart is
notified and performRequest() is excecuted, during which setContents() is
called and new EditPart(say NewEditPart) is created. Now, OldEditPart is
dettached from RootEditPart and GraphicalViewer. After setContents() and
performRequest(), the SelectionTool receive a MouseUp event and try to do
something. Here it getDragTracker() and try to call mouseDoubleClick().
Remember that the SelectionTool is still on OldEditPart but it is
DEACTIVATED. So something goes wrong in OldEditPart.....errrrr, I am tired
of tracing event dispatching system....
Looks like this:
|------------------------------DoubleClick------------------ ------------------|
/-->
SelectionTool.handleMouseDown()............handleMouseUp()-- >!!
MouseDown + |
\--> OldEditPart.performRequest(){..setContents()..}.....|
So, my solution is deactivate current tool (SelectionTool) before setting
contents:
performRequest(..)
{
...
getViewer().getActiveTool().deactivate(); // hey guy, don't bother
me!
setContents(..);
...
// should I re-activate the tool here?
}
Summary: it seems that EditPart(activate and deactivate) works pretty
well. However, the event system looks rather chaotic. The deactivate()
method protects the EditPart hierarchy, but it cannot prevents tools from
demolish the whole story.
Is it a bug, or it is just my fault to misunderstand the system?
Thanks!
> Please open a bugzilla for:
> 1) setting root editpart on viewer should deactivate old root
> 2) the stacktrace you get if you don't change the root editpart. Sounds
> like the drag tracker is doing something on mouse up, which comes after the
> double-click. I'm pretty sure there is a workaround to prevent this, since
> your editpart provides the dragtracker instance for selection.
> "Wang Ning" <wangning@db.pku.edu.cn> wrote in message
> news:bfm4gv$2rl$1@eclipse.org...
> > Gunnar Wagenknecht wrote:
> >
> > > Wang Ning wrote:
> >
> > > > getViewer().setRootEditPart(new ScalableFreeformRootEditPart());
> > > > getViewer().setContents(m);
> >
> > > Why setting a new RootEditPart? you should keep the current one and only
> set
> > > a new content.
> >
> > Well, say the replaced EditPart is A_EditPart. After setContents(), it is
> > detached from RootEditPart. However, A_EditPart.getViewer() is still
> > called and inside A_EditPart.getRoot() is called , which raises an
> > exception.
> >
> > I guest it is caused by the DragTracker, but not sure.
> >
> > Thanks!
> >
> > > Cu, Gunnar
> >
> >
|
|
|
| Re: A question about setContents() [message #88200 is a reply to message #88069] |
Thu, 24 July 2003 10:47 |
| Eclipse User |
|
|
|
Originally posted by: wangning.db.pku.edu.cn
Randy Hudson wrote:
How to open a bugzilla? I cannot connect to the server bug.eclipse....
I think I know where the problem is. I mean, I guess I know. When the user
double-clicks, a MouseDown event is dispatched and the SelectionTool is
activated on the EditPart, say OldEditPart. Then the OldEditPart is
notified and performRequest() is excecuted, during which setContents() is
called and new EditPart(say NewEditPart) is created. Now, OldEditPart is
dettached from RootEditPart and GraphicalViewer. After setContents() and
performRequest(), the SelectionTool receive a MouseUp event and try to do
something. Here it getDragTracker() and try to call mouseDoubleClick().
Remember that the SelectionTool is still on OldEditPart but it is
DEACTIVATED. So something goes wrong in OldEditPart.....errrrr, I am tired
of tracing event dispatching system....
Looks like this:
|------------------------------DoubleClick------------------ ------------------|
/-->
SelectionTool.handleMouseDown()............handleMouseUp()-- >!!
MouseDown + |
\--> OldEditPart.performRequest(){..setContents()..}.....|
So, my solution is deactivate current tool (SelectionTool) before setting
contents:
performRequest(..)
{
...
getViewer().getActiveTool().deactivate(); // hey guy, don't bother
me!
setContents(..);
...
// should I re-activate the tool here?
}
Summary: it seems that EditPart(activate and deactivate) works pretty
well. However, the event system looks rather chaotic. The deactivate()
method protects the EditPart hierarchy, but it cannot prevents tools from
demolish the whole story.
Is it a bug, or it is just my fault to misunderstand the system?
Thanks!
> Please open a bugzilla for:
> 1) setting root editpart on viewer should deactivate old root
> 2) the stacktrace you get if you don't change the root editpart. Sounds
> like the drag tracker is doing something on mouse up, which comes after the
> double-click. I'm pretty sure there is a workaround to prevent this, since
> your editpart provides the dragtracker instance for selection.
> "Wang Ning" <wangning@db.pku.edu.cn> wrote in message
> news:bfm4gv$2rl$1@eclipse.org...
> > Gunnar Wagenknecht wrote:
> >
> > > Wang Ning wrote:
> >
> > > > getViewer().setRootEditPart(new ScalableFreeformRootEditPart());
> > > > getViewer().setContents(m);
> >
> > > Why setting a new RootEditPart? you should keep the current one and only
> set
> > > a new content.
> >
> > Well, say the replaced EditPart is A_EditPart. After setContents(), it is
> > detached from RootEditPart. However, A_EditPart.getViewer() is still
> > called and inside A_EditPart.getRoot() is called , which raises an
> > exception.
> >
> > I guest it is caused by the DragTracker, but not sure.
> >
> > Thanks!
> >
> > > Cu, Gunnar
> >
> >
|
|
|
| Re: A question about setContents() [message #88215 is a reply to message #88188] |
Thu, 24 July 2003 10:49 |
| Eclipse User |
|
|
|
Originally posted by: wangning.db.pku.edu.cn
Wang Ning wrote:
Sorry for my duplicate messages.
And the sequence graph looks ugly after I posted it. Hope you can grasp my
problem just from the texts.
> Randy Hudson wrote:
> How to open a bugzilla? I cannot connect to the server bug.eclipse....
> I think I know where the problem is. I mean, I guess I know. When the user
> double-clicks, a MouseDown event is dispatched and the SelectionTool is
> activated on the EditPart, say OldEditPart. Then the OldEditPart is
> notified and performRequest() is excecuted, during which setContents() is
> called and new EditPart(say NewEditPart) is created. Now, OldEditPart is
> dettached from RootEditPart and GraphicalViewer. After setContents() and
> performRequest(), the SelectionTool receive a MouseUp event and try to do
> something. Here it getDragTracker() and try to call mouseDoubleClick().
> Remember that the SelectionTool is still on OldEditPart but it is
> DEACTIVATED. So something goes wrong in OldEditPart.....errrrr, I am tired
> of tracing event dispatching system....
> Looks like this:
>
|------------------------------DoubleClick------------------ ------------------|
> /-->
> SelectionTool.handleMouseDown()............handleMouseUp()-- >!!
> MouseDown + |
> --> OldEditPart.performRequest(){..setContents()..}.....|
> So, my solution is deactivate current tool (SelectionTool) before setting
> contents:
> performRequest(..)
> {
> ...
> getViewer().getActiveTool().deactivate(); // hey guy, don't bother
> me!
> setContents(..);
> ...
> // should I re-activate the tool here?
> }
> Summary: it seems that EditPart(activate and deactivate) works pretty
> well. However, the event system looks rather chaotic. The deactivate()
> method protects the EditPart hierarchy, but it cannot prevents tools from
> demolish the whole story.
> Is it a bug, or it is just my fault to misunderstand the system?
> Thanks!
> > Please open a bugzilla for:
> > 1) setting root editpart on viewer should deactivate old root
> > 2) the stacktrace you get if you don't change the root editpart. Sounds
> > like the drag tracker is doing something on mouse up, which comes after the
> > double-click. I'm pretty sure there is a workaround to prevent this, since
> > your editpart provides the dragtracker instance for selection.
> > "Wang Ning" <wangning@db.pku.edu.cn> wrote in message
> > news:bfm4gv$2rl$1@eclipse.org...
> > > Gunnar Wagenknecht wrote:
> > >
> > > > Wang Ning wrote:
> > >
> > > > > getViewer().setRootEditPart(new ScalableFreeformRootEditPart());
> > > > > getViewer().setContents(m);
> > >
> > > > Why setting a new RootEditPart? you should keep the current one and
only
> > set
> > > > a new content.
> > >
> > > Well, say the replaced EditPart is A_EditPart. After setContents(), it is
> > > detached from RootEditPart. However, A_EditPart.getViewer() is still
> > > called and inside A_EditPart.getRoot() is called , which raises an
> > > exception.
> > >
> > > I guest it is caused by the DragTracker, but not sure.
> > >
> > > Thanks!
> > >
> > > > Cu, Gunnar
> > >
> > >
|
|
|
| Re: A question about setContents() [message #88960 is a reply to message #88188] |
Tue, 29 July 2003 10:51 |
| Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
The correct way to do this is probably to override
SelectEditPartTracker.performOpen(). See EditPart.getDragTracker(...)
Could you post the exact stack trace that you were getting?
"Wang Ning" <wangning@db.pku.edu.cn> wrote in message
news:bforht$421$1@eclipse.org...
> Randy Hudson wrote:
>
> How to open a bugzilla? I cannot connect to the server bug.eclipse....
>
> I think I know where the problem is. I mean, I guess I know. When the user
> double-clicks, a MouseDown event is dispatched and the SelectionTool is
> activated on the EditPart, say OldEditPart. Then the OldEditPart is
> notified and performRequest() is excecuted, during which setContents() is
> called and new EditPart(say NewEditPart) is created. Now, OldEditPart is
> dettached from RootEditPart and GraphicalViewer. After setContents() and
> performRequest(), the SelectionTool receive a MouseUp event and try to do
> something. Here it getDragTracker() and try to call mouseDoubleClick().
> Remember that the SelectionTool is still on OldEditPart but it is
> DEACTIVATED. So something goes wrong in OldEditPart.....errrrr, I am tired
> of tracing event dispatching system....
>
> Looks like this:
>
>
|------------------------------DoubleClick------------------ ----------------
--|
> /-->
> SelectionTool.handleMouseDown()............handleMouseUp()-- >!!
> MouseDown + |
> \--> OldEditPart.performRequest(){..setContents()..}.....|
>
> So, my solution is deactivate current tool (SelectionTool) before setting
> contents:
>
> performRequest(..)
> {
> ...
> getViewer().getActiveTool().deactivate(); // hey guy, don't bother
> me!
> setContents(..);
> ...
> // should I re-activate the tool here?
> }
>
> Summary: it seems that EditPart(activate and deactivate) works pretty
> well. However, the event system looks rather chaotic. The deactivate()
> method protects the EditPart hierarchy, but it cannot prevents tools from
> demolish the whole story.
>
> Is it a bug, or it is just my fault to misunderstand the system?
>
> Thanks!
>
> > Please open a bugzilla for:
> > 1) setting root editpart on viewer should deactivate old root
> > 2) the stacktrace you get if you don't change the root editpart. Sounds
> > like the drag tracker is doing something on mouse up, which comes after
the
> > double-click. I'm pretty sure there is a workaround to prevent this,
since
> > your editpart provides the dragtracker instance for selection.
>
> > "Wang Ning" <wangning@db.pku.edu.cn> wrote in message
> > news:bfm4gv$2rl$1@eclipse.org...
> > > Gunnar Wagenknecht wrote:
> > >
> > > > Wang Ning wrote:
> > >
> > > > > getViewer().setRootEditPart(new ScalableFreeformRootEditPart());
> > > > > getViewer().setContents(m);
> > >
> > > > Why setting a new RootEditPart? you should keep the current one and
only
> > set
> > > > a new content.
> > >
> > > Well, say the replaced EditPart is A_EditPart. After setContents(), it
is
> > > detached from RootEditPart. However, A_EditPart.getViewer() is still
> > > called and inside A_EditPart.getRoot() is called , which raises an
> > > exception.
> > >
> > > I guest it is caused by the DragTracker, but not sure.
> > >
> > > Thanks!
> > >
> > > > Cu, Gunnar
> > >
> > >
>
>
|
|
|
Goto Forum:
Current Time: Fri Jul 18 15:47:42 EDT 2025
Powered by FUDForum. Page generated in 0.09113 seconds |
Home