output missing arg names when not all required args are present?

Mar 10, 2010 at 11:40 PM

I frequently run into a situation with this tool where I didn't supply all the necessary args. It'd be really nice if the tool would list out the missing required arguments when that happens. Is anyone working on something like that? Should I add it to the source?

Mar 13, 2010 at 6:23 AM

Dear jcollum,

thank you for your interest in this software.

Your suggestion is appreciated and may be that a future release will fill this gap.

If with the last question ("Should I add it to the source?") you're proposing to extend library about this feature, feel free to do this.

As always every patch or extension not created by the author will be part of the official source tree only if approved.

Again, thank you.

Regards,

Giacomo

Apr 6, 2011 at 4:08 PM

Seems to be similar issue than here: http://commandline.codeplex.com/discussions/249258

Right now the user gets no clue what went wrong, there is just the usage page shown which is a bit too little in most cases...

Any plans on if and when this feature will be added?

 

Thanks for this really good library!

Regards,

Charly

May 3, 2011 at 2:15 PM

Is there an update on this feature? I, too, would be quite interested in this.

Jul 6, 2011 at 3:47 PM

Hi everyone,

version 1.8.0.7 beta uploaded today in source code repository starts to solve this problem.

Thank to everyone for support and interest in this software!

Regards,

Giacomo

Jul 11, 2011 at 1:02 PM

 

thx for implementing this feature!

how does it work? a reference to a sample would be appreciated

Jul 12, 2011 at 7:02 AM

Hi princecharles23 and all other users,

please check the sample in the source.

Anyway you should derive the target instance from CommandLineOptionsBase, and add code like this in the GetUsage method:

var help = new HelpText(_headingInfo);
//[...]
string errors = help.RenderParsingErrorsText(this);
if (!string.IsNullOrEmpty(errors))
{
    help.AddPreOptionsLine(string.Concat(Environment.NewLine, "ERROR: ", errors, Environment.NewLine));
}

I hope this can help who need to use this new feature.

Regards,

Giacomo

Jul 12, 2011 at 8:05 AM

Giacomo,

thx for the fast reply! this seems to work. but as stated by yourself its not jet fully functional.

e.g. when i have a typo in one of the option names there is no error message. (this is the most common error in my app)

anyways, when i call the GetUsage method manually (because i have to validate the parsed arguments even further. i want to show usage when there went something wrong) i get a NullReferenceException in HelpText class because options.LastPostParsingState is null:

public string RenderParsingErrorsText(CommandLineOptionsBase options)
        {
            Assumes.NotNull(options, "options");
            
            PostParsingState state = options.LastPostParsingState;
            var badOption = state.BadOptionInfo;
            // other violations requires BadOptionInfo to be initialized
            if (badOption == null && !state.ViolatesMutualExclusiveness)
                return string.Empty;

            var errorsText = new StringBuilder(_builderCapacity);

            if (state.ViolatesRequired)
                errorsText.AppendFormat(GetMessageText(MessageEnum.ParsingErrorViolatesRequired), badOption.NameWithSwitch);
            else if (state.ViolatesFormat)
                errorsText.AppendFormat(GetMessageText(MessageEnum.ParsingErrorViolatesFormat), badOption.NameWithSwitch);
            else
                errorsText.Append(GetMessageText(MessageEnum.ParsingErrorViolatesExclusiveness));

            return errorsText.ToString();
        }

and one more issue that's soon gonna come up is localization of error messages (but you probably know that yourself) ;-)

thx again!

regards!

Charly

Jul 13, 2011 at 8:38 AM

Dear users,

please remember that the parsing errors reporting subsystem is at embryonic stage

For now this subsystem record the first parsing error (and stops - or better the parser stops when it meet the first error), so you can't get a list of bad arguments (for now).

Things will change in upcoming release. Recording each error requires a deep upgrade of core parsing system, so I decided to make gradual changes.

This decision will prevent drastic changes that could adversely affect the robustness of the codealthough this feature is protected by unit tests.

Please be patient and you'll get a robust and correct error reporting subsystem...

Another thing, the localization of this feature is provided overloading GetMessageText(MessageEnum).

Thanks to all for using this code!

Regards,

Giacomo Stelluti Scala

Oct 4, 2011 at 8:21 PM

Hi all,

recently checked in version 1.9.0.1 alfa introduces the new parsing errors reporting subsystem.

Check out the project and learn from sample and unit tests...

Regards,

Giacomo

Jan 3, 2012 at 7:54 PM
gsscoder wrote:

Hi all,

recently checked in version 1.9.0.1 alfa introduces the new parsing errors reporting subsystem.

Check out the project and learn from sample and unit tests...

Regards,

Giacomo

Hi Giacomo,

this sounds great. Any chances you could post that new version to nuget?

Thanks

Jan 5, 2012 at 4:25 PM

Dear CadErik,

it's in my plans... I will try to do it as soon as it becomes possible.

Thanks for using (and I hope, having fun with) this library!

Giacomo