Skip to content

Enums are not case insensitive #198

Closed
@vmelamed

Description

@vmelamed

First off: great job, guys!

Small issue: it looks like even though the wiki states that option properties bound to enum values are case insensitive:

When specifying enum values, you don't need to respect case. Both app -g bye and app --greet-type REGARDS are allowed.

unfortunately, they are not. I have a program that for a line like this:

settings -s gogo -v 23 -t int

where -t is bound to an enum SettingType {Int, String, ...}, I get an error:

ERROR(S):
  Option 't, type' is defined with a bad format.

  -s, --setting      The name of a setting to be added or modified.

  -v, --value        The new value of the setting. The option is required if -s or --setting is specified.

  -t, --type         (Default: String) The case-sensitive type of the value of the setting. The option is not mandatory and if not specified, the
                     type will be either implied from the existing setting with the same name or it will be assumed to be 'String'. The most common
                     types are: String, Int, Guid, Decimal, Boolean, DateTime, Date, Time, Uri, TimeSpan. DateTime values are assumed to be UTC.

[...etc]

BadFormatConversionError
  StopsProcessing          = False
  Tag                      = ErrorType.BadFormatConversionError
  NameInfo                 = NameInfo
    LongName                 = type
    NameText                 = t, type
    ShortName                = t

But if I enter the command like this:

settings -s gogo -v 23 -t Int

all is good.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions