Editing - moving an edit (point) not working

[SpencerWilliams]

I have a feature service that was working in the initial beta (Feb. I think) for 2.0 - I disabled the ability to use the feature service (ie editing) due to some issues with the data form in the initial beta.  After about 200 code check-in's - something is preventing it from working fully.  As far as I can tell, everything works except when you try and reposition an edit.  It looks like it trys to move it, but then it "sticks".  I am able to click and drag multiple times and move the edit over a landmark after around 10 click+drags - when I revisit the application after closing it (to check to see if the edit "took") I find that the edit never moved at all - or at least wasn't saved as such.

I have also tried using the service in the example to see if it was a problem with my featureservice on the arcGIS server, but it has the same behavior there as well.

Has anyone from esri seen this behavior using the new edit features?  I removed all click events from the map and page, but that didnt seem to help. 

Thanks,

Spencer

[SpencerWilliams]

ok, so I figured it out - the 2.0 version that was released in May broke on FeatureDataForm.GraphicsSource as it changed from GraphicsCollection to Graphic - when I changed it to (sender as featurelayer).Graphics[0], it worked because I have an edit already created in the layer.  This breaks however, when there are no graphics in the feature layer.  How are you supposed to set graphicsSource without graphics?  Do you wait until there are graphics in the featureservice, and then set the graphicsSource to a graphic in the featureService?  That seems odd.

[SpencerWilliams]

after some testing i have determined the following - if a flare clusterer is utilized on the featurelayer where edits are present, you cannot reposition items.  Please let me know if this is by design or a bug.

Thanks,

Spencer

[BrooksShannon]

after some testing i have determined the following - if a flare clusterer is utilized on the featurelayer where edits are present, you cannot reposition items.  Please let me know if this is by design or a bug.

I'm seeing this behavior too. Has anyone else noticed it?  Or, Spencer, if you were able to figure out a workaround, would you be willing to share what you came up with?

Thanks!
Brooks

[SpencerWilliams]

I'm seeing this behavior too. Has anyone else noticed it?  Or, Spencer, if you were able to figure out a workaround, would you be willing to share what you came up with?

Thanks!
Brooks

You aren't going to like my workaround - and to be fair, I did not choose this based on the clusterer not working with edit layers.  I am using MapIT's SDS to serve up the data, my own code to do the storage (writes) to the DB, and a heavily modified version of morten's "edit" code (in the gallery) to handle the on screen editing.  It was the right thing to do in our situation.

Spencer

[BrooksShannon]

You aren't going to like my workaround - and to be fair, I did not choose this based on the clusterer not working with edit layers.  I am using MapIT's SDS to serve up the data, my own code to do the storage (writes) to the DB, and a heavily modified version of morten's "edit" code (in the gallery) to handle the on screen editing.  It was the right thing to do in our situation.

Spencer

Cool.  While we might not have to go to as great of lengths as you have 😉 (as our editing solution is basic enough that most everything else out of the box will cut it) this is kind of a weird issue to deal with that presents some problems.  The performance of drawing an OnDemand FeatureLayer with clustering is so much better than without clustering (in my limited testing) that it seems almost necessary to use a clusterer of some kind (even if it's a custom one).  However, the ability to move features is just as important in the application I'm designing.

Maybe I can try implementing my own Move command, similar to what you did when you implemented your on-screen editing functionality.  If this is a bug in the ESRI implementation of the Move command, that might do the trick.  Or perhaps they're aware of the issue and it will be resolved at 2.0 release, which would make life easier.

Morten and/or Dominique - are you aware of this issue?  I can't immediately conceive of a good workaround, but if you have any ideas for me to chew on, I wouldn't likely turn them down. 🙂

Thanks!
Brooks

[dotMorten_esri]

Editing the geometry in layers that are clustered is currently not a supported scenario. If you need to do edit a layer, please disable clustering.

[BrooksShannon]

Editing the geometry in layers that are clustered is currently not a supported scenario. If you need to do edit a layer, please disable clustering.

Thanks for letting me know, Morten. I appreciate it.