| Re: Bug in AbstractTool.viewerEntered()/Exited()? [message #78367] |
Wed, 07 May 2003 11:47  |
Eclipse User |
|
|
|
Originally posted by: none.us.ibm.com
This is a multi-part message in MIME format.
------=_NextPart_000_004D_01C3148E.79849730
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
I think more information is needed. handleMove is called from =
mouseMove, which sets the viewer, so why would the viewer be NULL?
Please put a breakpoint in AbstractTool on the last line displayed =
below:
public void mouseMove(MouseEvent me, EditPartViewer viewer) {
setViewer(viewer);
if (!isInputSynched(me)) {
boolean b1 =3D getCurrentInput().isMouseButtonDown(1);
To find out if the if block is being entered. If it is being entered, =
this has been corrected. Download the latest build and try your code =
again.
"Lauri Pesonen" <lauri.pesonen@iki.fi> wrote in message =
news:gfo8ytjhtvo.fsf@elan.cs.hut.fi...
>=20
> Basically I get a NullPointerException from
>=20
> TargetingTool.updateTargetUnderMouse()=20
>=20
> [more specifically in
> EditPart editPart =3D getCurrentViewer().findObjectAtExcluding(...
>=20
> getViewer() returns a null.]
>=20
>=20
> I'm drawing a connection from a node to another node. My =
implementation
> spawns a dialog box for the user to select the output the connection
> represents in the source node. The dialog is inherited from the JFace
> dialog class. When I click on OK and move the mouse, the
> NullPointerException is thrown.=20
>=20
> This does not occur when I create a node and a similar JFace dialog is
> spawned. And this did not happen with the 2.0 version of GEF. I think =
that
> the reason might be that the connection creation tools are left 'on' =
while
> node creation tools are reset after use.=20
>=20
> I debugged the code and found out that AbstractTool.reactivate() is
> called. reactivate() calls first deactivate() and then
> activate(). deactivate() sets the currentViewer of the tool to null, =
but
> activate() does not reset it to the current viewer.=20
>=20
> The call stack goes something like this (other stuff is called in =
between):
>=20
> AbstractTool.mouseMove()
> AbstractConnectionCreationTool.handleButtonUp()
> AbstractTool.handleFinished()
> AbstractTool.reactivate()
> AbstractConnectionCreationTool.handleMove()
> TargetingTool.updateTargetUnderMouse()
> AbstractTool.getCurrentViewer() // returns null and causes the NPE.
>=20
>=20
> So, my guess is that the reactivation of the connection creation tool =
is
> broken and should reset the currentViewer to the current viewer where =
the
> tool is active.=20
>=20
> If this is not the case, I have some really weird bug in my code and =
I'd
> very much appreciate all the help you can give me :)
>=20
> --=20
> Lauri
------=_NextPart_000_004D_01C3148E.79849730
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META http-equiv=3DContent-Type content=3D"text/html; =
charset=3Diso-8859-1">
<META content=3D"MSHTML 6.00.2723.2500" name=3DGENERATOR>
<STYLE></STYLE>
</HEAD>
<BODY>
<DIV><FONT face=3DArial size=3D2>I think more information is =
needed. =20
handleMove is called from mouseMove, which sets the viewer, so why would =
the=20
viewer be NULL?</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>Please put a breakpoint in AbstractTool =
on the last=20
line displayed below:</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT><B><FONT color=3D#7f0055 =
size=3D2>
<P>public</B></FONT><FONT size=3D2> </FONT><B><FONT color=3D#7f0055=20
size=3D2>void</B></FONT><FONT size=3D2> mouseMove(MouseEvent me, =
EditPartViewer=20
viewer) {<BR> setViewer(viewer);<BR></FONT><B><FONT=20
color=3D#7f0055 size=3D2> if</B></FONT><FONT size=3D2> =
(!isInputSynched(me)) {<BR></FONT><B><FONT color=3D#7f0055=20
size=3D2> boolean</B></FONT><FONT =
size=3D2> b1=20
=3D getCurrentInput().isMouseButtonDown(1);</P></FONT></DIV>
<DIV><FONT face=3DArial size=3D2>To find out if the if block is being =
entered. =20
If it is being entered, this has been corrected. Download the =
latest build=20
and try your code again.</FONT></DIV>
<DIV><FONT face=3DArial size=3D2></FONT> </DIV>
<DIV><FONT face=3DArial size=3D2>"Lauri Pesonen" <</FONT><A=20
href=3D"mailto:lauri.pesonen@iki.fi"><FONT face=3DArial=20
size=3D2>lauri.pesonen@iki.fi</FONT></A><FONT face=3DArial size=3D2>> =
wrote in=20
message </FONT><A href=3D"news:gfo8ytjhtvo.fsf@elan.cs.hut.fi"><FONT =
face=3DArial=20
size=3D2>news:gfo8ytjhtvo.fsf@elan.cs.hut.fi</FONT></A><FONT =
face=3DArial=20
size=3D2>...</FONT></DIV><FONT face=3DArial size=3D2>> <BR>> =
Basically I get a=20
NullPointerException from<BR>> <BR>>=20
TargetingTool.updateTargetUnderMouse() <BR>> <BR>> [more =
specifically=20
in<BR>> EditPart editPart =3D=20
getCurrentViewer().findObjectAtExcluding(...<BR>> <BR>> =
getViewer()=20
returns a null.]<BR>> <BR>> <BR>> I'm drawing a connection from =
a node=20
to another node. My implementation<BR>> spawns a dialog box for the =
user to=20
select the output the connection<BR>> represents in the source node. =
The=20
dialog is inherited from the JFace<BR>> dialog class. When I click on =
OK and=20
move the mouse, the<BR>> NullPointerException is thrown. <BR>> =
<BR>>=20
This does not occur when I create a node and a similar JFace dialog =
is<BR>>=20
spawned. And this did not happen with the 2.0 version of GEF. I think=20
that<BR>> the reason might be that the connection creation tools are =
left=20
'on' while<BR>> node creation tools are reset after use. <BR>> =
<BR>> I=20
debugged the code and found out that AbstractTool.reactivate() =
is<BR>>=20
called. reactivate() calls first deactivate() and then<BR>> =
activate().=20
deactivate() sets the currentViewer of the tool to null, but<BR>> =
activate()=20
does not reset it to the current viewer. <BR>> <BR>> The call =
stack goes=20
something like this (other stuff is called in between):<BR>> <BR>> =
AbstractTool.mouseMove()<BR>>=20
AbstractConnectionCreationTool.handleButtonUp()<BR>>=20
AbstractTool.handleFinished()<BR>> AbstractTool.reactivate()<BR>>=20
AbstractConnectionCreationTool.handleMove()<BR>>=20
TargetingTool.updateTargetUnderMouse()<BR>> =
AbstractTool.getCurrentViewer()=20
// returns null and causes the NPE.<BR>> <BR>> <BR>> So, my =
guess is=20
that the reactivation of the connection creation tool is<BR>> broken =
and=20
should reset the currentViewer to the current viewer where the<BR>> =
tool is=20
active. <BR>> <BR>> If this is not the case, I have some really =
weird bug=20
in my code and I'd<BR>> very much appreciate all the help you can =
give me=20
:)<BR>> <BR>> -- <BR>> Lauri</FONT></BODY></HTML>
------=_NextPart_000_004D_01C3148E.79849730--
|
|
|
| Re: Bug in AbstractTool.viewerEntered()/Exited()? [message #78476 is a reply to message #78367] |
Thu, 08 May 2003 03:55  |
| Eclipse User |
|
|
|
Originally posted by: lauri.pesonen.iki.fi
"Randy Hudson" <none@us.ibm.com> writes:
> I think more information is needed. handleMove is called from =
> mouseMove, which sets the viewer, so why would the viewer be NULL?
>
> Please put a breakpoint in AbstractTool on the last line displayed =
> below:
> public void mouseMove(MouseEvent me, EditPartViewer viewer) {
> setViewer(viewer);
> if (!isInputSynched(me)) {
> boolean b1 =3D getCurrentInput().isMouseButtonDown(1);
>
> To find out if the if block is being entered. If it is being entered, =
> this has been corrected. Download the latest build and try your code =
> again.
Yes, the block was being entered, and yes, the latest build fixed the
problem. Excellent. Thanks for all your efforts!
--
Lauri
|
|
|
Powered by
FUDForum. Page generated in 0.03375 seconds
Home