Log in

No account? Create an account

Source Code Release

Well, from March 9, next weekend extended into nearly 6 weeks. Too many irons in the fire extended the planned release date a bit (OK, quite a bit).

This release includes a couple of new features. I have separated the non-CAB specific functionality. The DevLynx.Utilities solution includes the ConfigurationStore, the DataAccess class, the new CommandLineArgument classes, and various helper classes. This new solution allows developers to access the auxiliary functionality without having to include the ShellApp and CAB. I did not, however, separate the help content for these non-CAB specific items.

The basics for command line argument support is included in this release. From the ShellApp documentation:

Command line arguments are a useful tool for temporarily modifying application options; however, configuration files should be used for any long term option changes. DevLynx.Utilities contains a simple method for handling command line arguments relying on .NET attributes and reflection.

The syntax for DevLynx.Utilities compliant command line arguments is as follows:
      [/|-|--]key[=|:]value | key

key is an identifier of any length greater than 1 containing only a-z, A-Z and 0-9. value may be either an identifier with the same restrictions as the key or it may be a string surrounded by double quotes (“) or a string surrounded by single quotes (‘). The optional prefix can be one of slash, dash or double dash. No space is allowed between the prefix and the key. If there is a value it must be separated from the key with a delimiter of an equal or colon character. No spaces are allowed between the key and the delimiter or the delimiter and the value. If the key has no corresponding value it is treated as a boolean value (it either exists or does not exist within the command line arguments).

The DevLynx.Utilities command line arguments are not positional; they cannot be programmatically accessed via an index. Instead they can be used in one of two ways:
• They may be programmatically accessed via the key identifier. In this case the value will be returned as a string.
• The preferred method is to create a class with properties decorated with the CommandLineArgumentAttribute attribute. The CommandLineArguments class will then fill the class properties with the corresponding values. In this case the value will be type safe and validated for the requested type.
A simple validation method may also be included in the data class of the DevLynx.Utilities command line arguments. This method will be called as soon as the instance of the data class is loaded.

Additional Restrictions:
• Duplicate key entries are ignored. The first argument with the key will set the value.
• Strings may not contain the character with which they are quoted.
• key entries are case insensitive.
• Boolean arguments without a value element will not change their corresponding properties to false if the argument does not exist on the command line; the value will remain as set in the class instance.

Currently, the command line arguments support only boolean and string values. Future enhancements will handle additional types.

There may be some readers who are interested in the ShellApp but don’t want to invest the time to examine the code at this early stage. I have uploaded a web version of the documentation so that you can see the current project state without downloading.

The current source code release, the web based documentation, and a PDF of the blog can be found on my web site at tetzel.com.



Command line parser

Hello, DevLynx.
Did you see this command line parser? http://www.codeproject.com/KB/recipes/plossum_commandline.aspx
In my opinion this is very powerful parser which satisfies all (my and hopefuly yours) needs. Try take a look.

Re: Command line parser


I did look at Plossum and a number of other command line argument classes. The Plossum one was the most complete one that I found and I considered it for some time. However, in the end, I wrote my own. There were really a couple of reasons for that. First, I wanted the experience with filling the properties of a class in a generic way. As someone who has done Delphi programming for many years, I need more experience in the C# philosophy; this small task was a way to gain some of that experience. Second, correctly or incorrectly, I perceived Plossum as more than I wanted. That I might be able to write something not as powerful but enough for my needs. So I attempted to write something that was a bit leaner. I hopefully achieved that goal.



Why are you not using project references?

today I am trying to compile your new source code and I am wondering you are not using project references. Is this "by design" or mistake?

What I mean is that e.g. DevLynx.Utilities.Library is referenced from Shell as .dll instead of project reference. Project references are preferred way:

Project-to-Project References and File References

Re: Why are you not using project references?


Being a Delphi guy, I am still learning some of the ins and outs of Visual Studio and C#. However, it was my impression that project references were only between projects in the same solution. I just got to the "day job" so I'll have to do the research tonight. Thanks for pointing me to something new...I love learning new things.


Re: Why are you not using project references?

Yes, you are right. Project references are references only between projects in the same solution. But in development phase there is normal practice to include support library (DevLynx.Utilities.Interface) in solution and reference it as project reference. It makes easy to refactor everything in solution. Without project references this is very difficult.

While I plunging deeper into your code, I must say that concepts used in your CAB application are very good. Thanks again!