ThinkGeo.com    |     Documentation    |     Premium Support

Ability to check for existance of a feature by Key

#1

I have added a custom feature to the EditOverlay with a specific Key. I would like to know the best way to test if this given feature exists before trying to recreate a feature with the same Key.



#2

I haven't used the EditOverlay. Looking at the code though, would this work?


 



 
InMemoryFeatureLayer layer = (InMemoryFeatureLayer)MapControl.EditOverlay.EditLayer;  
Feature searchedFeature = layer.InternalFeatures.FirstOrDefault(entity => entity.Id == "My Key");   
if (searchedFeature != null)  
{     
///...  
} 



#3

Brendan,  
  
 I tried your code and come up with some ideas that 
 1, MapControl.EditOverlay.EditLayer is an InMemoryFeatureLayer already, so you don’t need to do the conversion. 
 2, I couldn’t find the method FirstOrDefault, that’s one of your Extension Method, right? 
 3, just want to provide a simple explanation about that Lambda Expression in case some guys don’t very sure about it. 
  
 The argument of FirstOrDefault is a handler, and here we passed a concrete method Entity =>entity.id == “My Key” that means for whatever entity you input, if its id equals to “My Key”, it returns true otherwise returns false.  
  
 Also, here is a simpler solution which does not use the extension method. 
  
 
            if (winformsMap1.EditOverlay.EditLayer.InternalFeatures.Contains("My Key"))
            {
                /// …
            }
 
 Thanks, 
  
 Ben 


#4

1. MapControl.EditOverlay.EditLayer is an InMemoryFeatureLayer already, so you don’t need to do the conversion.

[Yes ur right, Initially I was trying to cast from another collection as i was finding my way through the code, and forgot the cast in there]



2. I couldn’t find the method FirstOrDefault, that’s one of your Extension Method, right?

[It's a standard Linq extension method found in the "System.Linq.Expressions" namespace, and will safely return a null if a result is not found... and this is what i was testing for when checking if the searched item was null:P]



Also, here is a simpler solution which does not use the extension method. [Ah, I didn't see that, thanks:P I wonder if that's using a for / foreach / linq statement / action]

 


Regards,


Brendan



#5

Brendan, 
  
 Thanks for letting me know. I had a test and I think it should be “System.Linq” namespace I need to import for the built in Extension Methods. Here is a small sample for that. 
  
 
using System;
using System.Linq;

namespace ConsoleApplication1
{
    class Program
    {
        static void Main(string[] args)
        {
            int[] numbers = { };
            int first = numbers.FirstOrDefault();
        }
    }
}
 
  
 I’m not sure which action “Contains” is using, may be “for”, as “Contains” doesn’t exist in IEnumerable, if it is using foreach, maybe MicroSoft would also add it to IEnumerable. Just guess :) 
  
 Thanks, 
  
 Ben 


#6

Actually, with the extension methods it does: msdn.microsoft.com/en-us/library/bb352880.aspx. 
  
 As far as I know, IEnumerable.Contains is only implemented for the IEnumerable interface and not the IList interface. 
  
 The only reason I noted it was purely because the Contains method in question is a ThinkGeo custom method on the GeoCollection class (which references System.Reflection - makes me nervous:P). The generic Contains methods in the framework require a matching object to be passed in (and preferably an IEqualityComparer - which is quite useful when working with complex classes). 
  
 Anyway, this is off topic and not too important. 


#7

Thanks for everything, guys. I was able to work around my particular issue but the flexibility to test for a features extistance by Key on demand will come up again soon!


Thanks again.



#8

Nelson, 
  
   I am not quite sure I follow you.  When you add the feature to the EditLayer.InternalFeatures you can specify your key as it is a dictionary.  You can also call the Contains or ContainsKey on the dictionary also.  You can later just get it back using the key.  I think I am missing something or not reading you reply right.  Maybe I don’t know this API well enough.  Can you elaborate a little? 
  
 David

#9

I think at the time I overlooked or missused the Contains method. The scenario I was bumping into was related to an event firing off during my FormLoad and by fixing this I had no need to check by key since I could always ensure the feature was added to the map onload before the ExtentChanged event fired off. So, User Error!  
  
 But yes, the Contains function looks like it would do exactly what I had asked. 
  
 Thanks again to everyone.

#10

Nelson, 
  
   Thanks for clearing that up.  I thought I was in the twilight zone for a bit.  I saw Ben & Brendan talking about  everything from Linq to Extension Methods. :-) 
  
 David

#11

hence my comment "Anyway, this is off topic and not too important." :P

#12

Brendan, 
  
   You caught me.  I am a skimmer…  If I actually read all these posts I might loose my mind! 
  
   On thing, while we are on the subject, is that the extension methods are really slick!  There is a dark side though I found.  If you use them allot on common objects people start to get confused when reading your code.  They seem shocked that X object has Y method.  They know the objects pretty well and it throws them for a loop.  It can make your code really simple though to encapsulate stupid loops logic into one sweet line of readable power code. 
  
 David