Using dragTo into GEF canvas causes problems

[eeybye]

Hello

In our application, I want to drag from a tree view to a FigureCanvas.

To get this working, I'm using a TreeItemLocator and afterwards using:
ui.dragTo(new LRLocator(1, new NamedFigureLocator("A")));

NamedFigureLocator returns two objects, so thats why I'm using the LRLocator.

The above code causes a null pointer exception, but I'm not sure whether it's my code or not.

java.lang.NullPointerException
at com.windowtester.event.swt.UIProxy.getBounds(UIProxy.java:75)
at com.windowtester.runtime.swt.internal.dnd.DragAndDropHelper.getBounds(DragAndDropHelper.java:344)
at com.windowtester.runtime.swt.internal.dnd.DragAndDropHelper.dragTo(DragAndDropHelper.java:167)
at com.windowtester.swt.UIContext.dragTo(UIContext.java:413)
at com.windowtester.runtime.swt.internal.UIContextSWT.doDragTo(UIContextSWT.java:437)
at com.windowtester.runtime.swt.internal.UIContextSWT.dragTo(UIContextSWT.java:426)
at testt.testtestt(testt.java:94)

I have tried calling getBounds on the returning IFigure, and its valid.

Another thing. Is there a way to pass a parent locator for NamedFigureLocator ??

Thanks in advance.

[Phil Quitslund]

Thanks for reporting this. Are you using the latest beta? We recently added some fixes that may address this. If the problem persists, please send a bug report to wintest-support@instantiations.com. This will open a ticket in our bug-tracking system and we can schedule a fix.

As for your query:

Another thing. Is there a way to pass a parent locator for NamedFigureLocator ??

NamedFigureLocators do not currently take parent information into account. (The thought being that unique names should not need disambiguation via information about parents.) If this is an important feature for you, please submit a feature request to support.

Alternatively, you can always create your own IFigureMatcher implementation that matches on whatever criteria you identify and pass this matcher into a FigureLocator. That is, something like:

Code: Select all

class MyFigureMatcher implements IFigureMatcher { ... }

class MyFigureLocator extends FigureLocator {
    MyFigureLocator(..) {
       super(new MyFigureMatcher(..));
   }
}

If this feels like a direction you want to pursue and you need help building your matcher, let us know and we'd be happy to help.

Thanks!

[eeybye]

Thanks for the quick response. I was testing with the latest beta.

You are right regarding the id, it should be unique and it actually is. My problem is, that the Editor contains two FigureCanvas, which then contains the same id. Only one FigureCanvas is visible at a time though. I can hopefully build that in a custom FigureLocator.

[Phil Quitslund]

It actually sounds like the visibility check should be in our default matcher implementation. (In which case we should really fix this on our end and you would not need to create a locator of your own...)

Does this sound right to you? Let us know what you think --- in the meantime, we'll investigate any downsides to this adjustment in matcher semantics.

[eeybye]

It sounds very good if you could do the visibility check. That will save me for some maintainability in the future.

[Phil Quitslund]

Great. I've submitted a feature request.

More as soon as we have it implemented!

[Phil Quitslund]

This has been implemented and is in our latest beta findable here:

http://www.instantiations.com/windowtes ... nload.html

For Eclipse 3.4 users, do note that the provisioner for eclipse 3.4 (p2) has a bug that will require you to take a few extra steps when you install:

http://downloads.instantiations.com/Win ... oblem.html

Thanks again for your help in tracking this down!

-phil