ThinkGeo.com    |     Documentation    |     Premium Support

Deleting a selected feature from EditOverlay

#1

Guys,


is this allowed?  If so, why does the following not get rid of the feature from the map?


 


TIA.



 internal void DeleteSelectedGraphics()
        {                     
            var feature = highlightLayer.InternalFeatures[0];

            map.EditOverlay.EditShapesLayer.Open();
            map.EditOverlay.EditShapesLayer.EditTools.BeginTransaction();
            map.EditOverlay.EditShapesLayer.EditTools.Delete(feature.Id);
            map.EditOverlay.EditShapesLayer.EditTools.CommitTransaction();
            map.EditOverlay.EditShapesLayer.Close();

            //map.EditOverlay.EditShapesLayer.InternalFeatures.Remove(feature.Id);
          
            highlightLayer.InternalFeatures.Clear();

            map.Refresh(new Overlay[] { map.EditOverlay,highlightOverlay });

        }


#2

Guess what I need to understand is the how the EditOverlay and TrackOverlays work together on the map. If someone can brief me on these these work, it would be very helpful, thanks.



#3

Problem solved but will like to make a comment as I suspect that this is probably related to this post. 


gis.thinkgeo.com/Support/Dis...fault.aspx


You guys need to properly document overlaoded methods of your custom collections and the consequencies that result if someone uses them.  Especially if you are overloading the .NET framework methods, as some of us expect a certain behavior.


For instance, it is a common theme in your custom collections that if one calls  Add(string, T) instead of adding Add(T) , the object T cannot be removed from the collection by calling Remove(string), if this object has an Id or Name field.  This appies to your GeoCollection in particular.  Because this collection is used in a lot of places, it throws some of us off.


For example, i expected that if I simply call Add(T) and this collection supports Remove(string), then the collection will , behind the scenes, use Add(string, T) so that I can Remove(string) later.


I could not delete a selected feature because I was adding it to the InternalFeatures collection of the EditOverlay's shapefile layer using Add(feature) instead of Add(feature.Id, feature).  So when I called Remove(feature.Id), nothing happened and no exception was thrown.


Just an observation.



#4

Hi Klaus, 
  
 The GeoCollection.Add(T) makes a Guid as its default key, so that you cannot find the feature back by its id. 
  
 I see that you want our GeoCollection<T> behaves like a KeyedCollection<T> that every item has an identifier like “Id”; you can simply add item in to the collection by Add(T) and remove the item by Remove(string). It’s quite simple and I agree with you. 
  
 Or you want one of the overload of Add(T) makes the identifier as the default key. But one advantage of GeoCollection is that it allows adding the same item multiple times; while if we change it, it doesn’t support. On the other hand, GeoCollection is a generic collection which means we cannot force the generic type has a fixed identifier; for example feature has Id property, but how about overlay or marker or some custom types? 
  
 So when using GeoCollection, we recommend using Add(T) when you don’t want to find items back; while using Add(string, T) when you want to. 
  
 Hope it makes sense. 
  
 Thanks, 
 Howard

#5

Howard, it all makes sense.  Again, thanks for the detailed explanation. 


Your API signatures are, in most cases, self describing but in other cases, like this you guys should consider adding a little more documentation to the method signatures.



#6

Hi Klaus, 
  
 I see; actually we are doing a new Wiki project that will integrate all our APIs, documentations, samples, code communities into it. When it’s published, everything you need can be found there; for example if the documentation of GeoCollection is pool, our developers or supports can simply modify the existing documentation and you will always get the latest updates on the Wiki. Now it’s still in progress, just keep an eye on our website for the updates. 
  
 Thanks, 
 Howard