Hi for the second time! Old school ini files and Com Ports!

Are you missing the existence of Enum.Parse?

Handshake handshake = (Handshake)Enum.Parse(typeof(Handshake), Key[1]);

Or make yourself a utility method

public static T ParseEnum<T>(string value) { return (T)Enum.Parse(typeof(T), value); }

and call it

Handshake handshake = ParseEnum<Handshake>(Key[1]);

Not clear what is the problem. If would only recommend to get rid of all immediate constants, especially strings you hard-coded in your sample like "EUIUBOARD", "BOARDRATE", etc. (Also, there is no such work "boardrate", its "baud rate", see http://en.wikipedia.org/wiki/Baud_rate[^].) A compiler won't detect a problem if you misspell it, change it during support. So, this is not maintainable. One of the robust ways is using enumeration types.

For example:

enum Key = {
    BoudRate = 0, //0 by default, assigned just to indicate is should not be modified if you want to use Length
    DataBits,
    StopBits,
    FlowControlRtsSts,
    FlowControlDtrDsr,
    FlowControlXonXOff,
    //?
    Length, //this is not a semantic but a "technical" member, see below
}

string iniKey = //... something from INI file you want to compare, like your Key[0]...
for (Key key = 0; key <length,>    if (iniKey.ToUpper() == key.ToString().ToUpper()) {
        // you have a match, process value now
        //...
        break;
    } //if
    //...
}

You see, not a single immediate string constant is hard-coded here. The key name is got from the enumeration member via key.ToString.

For simple tasks this is good enough, but you should remember the special meaning of Length as you mix semantic enumeration members with non-semantic Length, cannot use non-consecutive enumeration members, a value range starting from a non-zero value. Sometimes you need all that. So, for more advanced techniques, please read my article: Enumeration Types do not Enumerate! Working around .NET and Language Limitations[^].

[EDIT]

As to INI storage, you can save a lot of development time if you cut it down and switch to more comprehensive technology. The best thing I know is using Data Contract. With this approach, you won't have to care about persistence of the data at all, but the class System.Runtime.Serialization.DataContractSerializer or System.Runtime.Serialization.Json.DataContractJsonSerializer will. You will only need to code data classes representing data and add DataContract and DataMember attributes to what you need to be a part of a contract. See:
http://msdn.microsoft.com/en-us/library/ms733127.aspx[^] (using Data Contracts),
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.datacontractserializer.aspx[^],
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.json.datacontractjsonserializer.aspx[^],
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.datacontractattribute.aspx[^],
http://msdn.microsoft.com/en-us/library/system.runtime.serialization.datamemberattribute.aspx[^], see also related topics.

This approach will make you completely free from manual XML or JSON programming; it will also give you highly maintainable code, with wonderful mechanism of backward compatibility and more.

Good luck,

—SA