Processor Flow Editor Sample App

JGo
1

Hi,

I have a quick question and I’m not sure its been addressed in later releases although it appears to occur in the 5.40 eval copy too.

I’ve noticed that when single clicking on one of the palette items (lets say start) and dragging it on to a view, the first drag fails. No object is created in the view.

Then if you click on another object (the finish) in the palette and drag that to the view rather than creating that object in the view it creates the first object (the start) that you attempted to drag, which failed to be dragged first. This appears to then repeat if you click and drag an item, it always drops the last item attempted to be dragged.

The only way of avoiding this is to double click the item in the palette before dragging it.

Is there away around this behavior. It does not seem to be an issue for the likes of the Demo1 app.

Thanks

Wayne

2

Hi Wayne,

I’m not seeing the behavior you describe. Are you using the unmodified processor.jar file that’s included in the toplevel directory of the kit or have you rebuilt it and/or modified it? Also, which flavor of JGo are you using, Swing or SWT? Also what operating system and JRE are you using?

In general, the Processor sample is using standard JGo drag and drop, which in turn is using standard Java drag and drop. The JGoView implements DragGestureListener, DragSourceListener and DropTargetListener. Both the source of the drag and the target of the drop are JGoViews (JGoPalette inherits from JGoView). Nothing has changed in this area for many years, so I’m surprised it is not working correctly for you.

  • Scott
3

Hi Scott,

Yeah I was surprised as you were I’ve not touched JGo in a while and did not recall seeing this before but that was on older version and I imemdietly thourght it was me doing something wrong until I saw the processor app doing the same thing.

Anyway its the unmodified Swing version running on JRE 1.6.0_26. I even tried the one in the 5.40 eval kit just to make sure. Although I think it is somewhat environmental. I’ve just tried it on two other machines with the same Java versions and same OS (Windows XP Professional) and get the results you would expect. I.e. it works fine. But on my main dev machine its has this strange behaviour. I’ll see if I can try and track down something, may its a path issue or something like that thats messing with it

If on the off chance anyone else has encountered this issue and solved it any pointers would be helpful as to what it is.

Cheers and Happy New Year
Wayne

4

I have had the exact same issue for a long time but haven’t been able to
track it down until now. It’s only repeatable if you are really quick
with the mouse. The cause seems to be that the object is not selected
until the first MouseMotion event is triggered and if you move away from the view without triggering one the object that you want to copy will thus not be selected. If you try to drag-copy
something that is close to the edge of the view it is quite easy to
trigger the issue, i.e. click the object and quickly move the pointer
away from the current view.

Another symptom for this issue is that you can copy the previously
selected object instead of the one that you think you are dragging.

I
discovered the issue in version 5.0 and verified that it still exists
in the 5.40 evaluation version. I have been able to trigger the issue on
both Windows 7 and Linux (various Fedora releases and in both Gnome and
KDE).

5

Workaround code in a class extending JGoView (not extensively tested):

@Override
public boolean doMouseDown(int modifiers, Point dc, Point vc) {
  boolean consumed = super.doMouseDown(modifiers, dc, vc);
  if ((modifiers & (InputEvent.SHIFT_MASK | InputEvent.CTRL_MASK)) == 0 && getState() == JGoView.MouseStateSelection) {
    JGoObject obj = pickDocObject(dc, true);
    if (obj != null && !getSelection().isSelected(obj)) {
      getSelection().selectObject(obj);
    }
  }
  return consumed;
}
6

Selecting an object, then starting a link from another object and dropping on another view also copies the selected object. The behavior is similar to the issue above. However for this operation you do not really have a particular behavior to expected.