ThinkGeo.com    |     Documentation    |     Premium Support

"Default" enum values

There are several new enums with Default members in RC1 that have rather ambiguous values.  For example, MapLeftClickDragMode has three members with the following values:



        
  • Default = 0

  •     
  • ZoomInWithKey = 1

  •     
  • Disabled = 2


Given that Default member does not share a value with either of the two other members, it looks like the Default member maps to some third option.  However, as far as I can tell, the default option for ExtentInteractiveOverlay.LeftClickDragMode is in fact ZoomInWithKey.  If this is the case, the enum Default and ZoomInWithKey options should share a value.  e.g.:


public enum MapLeftClickDragMode

{

    Default = 0,

    ZoomInWithKey = 0,

    Disabled = 1

}


Another, perhaps even better option, would be to get rid of the Default member entirely after mapping the actual default behaviour to the 0 value in the enum.  e.g.:


public enum MapLeftClickDragMode

{

    ZoomInWithKey = 0,

    Disabled = 1

}


 If there really is meant to be a third behaviour, the corresponding enum member should be explicitly named rather than using the rather vague name "Default".

 



I took a training session yesterday, and we discussed this.   It is actually a pretty common practice.   With default, you are basically saying “I want to use ThinkGeo’s suggested behavior, and I’m willing to accept that this behavior might change over time, based upon user experience and other factors”.    So, yes, today, Default and ZoomInWithKey might behave the same, but in an August build, based upon feedback, default might change to some other new and improved tool. 
  
 I see this a lot in other third-party licenses I use, too.   Sometimes the behavior of default might vary based upon a system setting.   For instance, default might do one thing on desktop machine, and a different thing on a tablet machine w/o a keyboard.   Or default might indicate you want to use a master skin value that is set in some other component. 
  
 Sorry for butting in, but if we are voting, I would like to vote to preserve the “default” option.

Ted,


I agree that the scenarios that you describe are compelling.  If that is in fact the intended usage of the Default option, I would agree that it should be conserved as-is.  However, there really needs to be something in the docs for any property that exposes such an enum that describes what the Default option means in its particular case.  Otherwise, one is stuck reflecting into the enum to try to see what the Default value is, which doesn't much help when it doesn't match an existing value...


Nicole



Yes, the docs need to indicate the intended use of default at a high level, and the precise behavior on specific instances.

Nicole & Ted, 
  
 Thanks for your posts and sharing! 
  
 I think this is exactly what Ted suggested, currently, we are suggested to put the default value to make the whole map system operation normal and easy to use. Maybe some time later, we would change some of the default values based on the customer feedback or we add new functionality to make it customable with that time. 
  
  Yes, I think there are many places need to be enhanced in our Doc system. Thanks for your suggestions. 
  
 Any more questions just let me know. 
  
 Thanks. 
  
 Yale