ThinkGeo.com    |     Documentation    |     Premium Support

E.DraggedFeature bug

#1

Hi!


I found another bug. When I have a feature in
the EditShapesLayer of map.EditOverlay the user can drag, rotate and resize
the feature.


 


This works as it's supposed to. I've added
eventhandlers for the FeatureDragged, FeatureRotated,and
FeatureResized, which give me access to e.DraggedFeature,
e.RotatedFeature and e.ResizedFeature respectively. 


 


e.RotatedFeature
and
e.ResizedFeature return the feature with its shape intact. However, e.DraggedFeature
returns the feature
with correct ColumnValues and Tag etc, but its wellknowntype
has suddenly become a Point. 


 


I've seen this happening with multipointshape
and multilineshape features, but it may be true for other types of features
too. 



I'm on build 7.0.287.0. 



#2

Hi F5K, 
  
 Thanks for reporting this, now we have fixed it would you please get the latest dll 7.0.289.0(still in build) and try it again? 
  
 Thanks, 
  
 Summer

#3


I've just
downloaded 7.0.293.0, but I don't see any improvement.

  

Additionally,
I've played around some more with these events and found the following


For FeatureDragged,
FeatureResized and FeatureRotated: 


        
  1. As
        mentioned before, e.DraggedFeature always returns a point feature 

    2.     
  2. FeatureDragged
        is fired once, when the user is done dragging and has released the mouse. The
        other two events fire continuously while dragging the feature.

    3.     
  3. When
        I resize a rectangle, the FeatureDragged event is triggered instead of the
        FeatureResized event. I do not know what happens when I rotate the rectangle as
        I've overidden CalculateRotateControlPointsCore in EditInteractiveOverlay so that
        rectangles cannot be rotated. Otherwise my rectangle implementation is the same
        as in the rectangle example. 


For
FeatureDragging, FeatureResizing and FeatureRotating:


        
  1. These
        events are fired continuously, but the shapes of e.DraggingFeature,
        e.ResizingFeature and e.RotatingFeature are never updated. 

    2.     
  2. In
        the case of non-rotatable rectangles, resizing doesn't trigger any of the
        events. 


 I would
have expected that FeatureDragging, FeatureResizing and FeatureRotating kept me
continuously up to date on the new shape of all types of features, and that FeatureDragged,
FeatureResized and FeatureRotated would give me the final shape once the user
has released the mouse button. 



Your help is much appreciated.



#4

Hi,


I agree with you that the e.DraggedFeature always returns a
point feature, while for e.ResizedFeature, e.RotatedFeature returns the update
to date new shape of the feature. I guess this is not a bug but from the design,
however not very sure. Now the workaround is that create a custom
EditInteractiveOverlay by overwriting MouseUpCore method, just shown as
following to achieve what you want:


protected override InteractiveResult MouseUpCore(InteractionArguments interactionArguments)
{
    InteractiveResult result = new InteractiveResult();
    result.DrawThisOverlay = InteractiveOverlayDrawType.Draw;
    result.ProcessOtherOverlaysMode = ProcessOtherOverlaysMode.DoNotProcessOtherOverlays;
    if (OriginalEditingFeature != null)
    {
        FeatureDraggedEditInteractiveOverlayEventArgs featureDraggedEventArgs =
            new FeatureDraggedEditInteractiveOverlayEventArgs(OriginalEditingFeature);
        OnFeatureDragged(featureDraggedEventArgs);
    }
    return result;
}


When we resize a
rectangle, the FeatureResized event is fired, and then FeatureDraged event is followed. I guess you
can override “RotateFeatureCore”
as following statements to manage what you want:




protected override Feature RotateFeatureCore(Feature sourceFeature, PointShape sourceControlPoint, PointShape targetControlPoint)
{
    ………
}


If you want to update
the feature when “FeatureDragging/featureRotating/FeatureResizing” is fired.  You can override “RotateFeatureCore/ResizeFeatureCore”.



Hope it helped,



Thanks,

Johnny



#5

Hi Johnny, 
  
 I’m afraid your override of MouseUpCore results in unexpected behavior. When I put the mouse button down I can start moving the map around (= normal), but then when I release the mouse button, the program remains stuck in this moving the map mode.  
  
 Also, when moving a feature I have to click once to start dragging it and a second time to stop dragging it (rather than the normal mousedown mouseup behavior). This second click then adds unwanted control point to my feature.  
  
 When I scroll to zoom in and out the features regularly disappear and at one time the whole program crashed when I kept scrolling.  
  
 It seems there is a lot that mouseCoreUp used to do, but is no longer done when I override it.  
  
 Could you please help me solve these problems?

#6

Oh no! It gets worse. 
  
 Since I’ve updated to 7.0.296.0 the FeatureDragged event fires even when I’m not dragging a feature, but merely move the map. I’m talking about standard behavior now, so without the overrides you proposed.  
  
 The behavior is rather similar to the bug discussed in thinkgeo.com/forums/MapSuite/tabid/143/aft/11881/Default.aspx, but now concerning the FeatureDragged event, rather than VertexAdded.

#7

I’ve just tested with an older DLL(7.0.0.151) and found out that FeatureDragged used to behave exactly like FeatureResized and FeatureRotated. So it used to return the updated feature (and not a point feature) and it used to be fired continuously while dragging the feature.  



Can you please help me get this functionality back?

#8

Hi,



We have correct the return feature from drag point to updated feature. In other words, we have rollback the code here, please get the latest development version 7.0.302.0 or later to have a try. 



However, we are unable to recreate the issue related to “MouseMove”, I’m not sure if we missed something here, could you try the attached sample to do some changes? Also here is a video on our test screencast.com/t/U5TRbEDDf.



Thanks,
Johnny

WindowsFormsApplication40.zip (11.6 KB)

#9

That’s very good news! I’m looking forward to testing out 7.0.302.0. As of now it isn’t available yet; the latest daily development build is from April 2 (7.0.296.0).  
  
 Thanks also for the video and the sample code.  
  
 Concerning the map move problem, it seems the order in which things are done is important. If I do like you in the video i.e. first move the map and then move the feature, everything is fine. However, once the feature has been moved at least once, then moving the map suddenly causes FeatureDragged to fire. I tested this with your sample code.  
  
 You help is much appreciated.

#10

Hi, 
  
 We have fixed this issue, it can be available in the latest development branch 7.0.303.0 or later, please try it. 
  
 Thanks, 
 Johnny

#11

I’ve tested 7.0.302.0 and the point feature part has indeed been fixed! Thank you very much! I’ll check out 7.0.303.0 when it becomes available.

#12

I cheered too early :’-(



e.DraggedFeature now (7.0.302.0) contains the right feature, but with the shape it had before it was dragged…

#13

Hi,  
  
 Thanks for let us know the problem, we have fixed it, it can be available in the latest development branch 7.0.304.0 or later, please try it.  
  
 Regards,  
  
 Don

#14

I’ve tried 7.0.303.0 and I can now move the map after moving a feature without triggering FeatureDragged. We’re getting closer :-) Thanks for your help so far. I’ll try out 7.0.304.0 when it becomes available.

#15

Hi,  
  
 Any question please let us know.  
  
 Regards,  
  
 Don

#16

All issues are gone in 7.0.313.0 
  
 Thanks!

#17

Hi, 
  
 We are glad to hear the issue is solved. 
  
 Regards, 
  
 Don