ARRL DX: accept 1TT or 100 as valid power entries

[w7sst]

• allow cut numbers to be supported as power entries
• user is able to log what they hear
• display logged exchange value in screen log
• fixes MR should accept 1TT or 100 as valid power entries #145

[K6OK]

Later on when user-supplied Cabrillo history files are supported, then TrueExch2 might be 1TT or ATT instead of 100, depending on what file they use. ARRLDXCW_USDX.txt only has 100 and no cut numbers. Might need to do this?

701 etPower: if ReducePowerStr(TrueExch2) <> ReducePowerStr(Exch2) then Err := 'PWR';

[w7sst]

Thank you for testing both domestic and DX sides of this contest. I appreciate it.

1. I updated regular expressions for ATT, Aoo, A00 or NN. Also allow them to be entered into exchange fields. This regex is now: '([0-9]*)|(K)|(KW)|([0-9A]*[OTN]*)'.
2. For the domestic runner case above, I did changed the regular expression for states/provinces to expect two characters making up US state or VE province: '[ABCDFGHIKLMNOPQRSTUVWY][ABCDEFHIJKLMNORSTUVXYZ]'. This will reject the 'K' or the 'KW' and accept any valid state or province.

I posted an updated build for further testing.

[f6fvy]

I'm not sure that restricting the chars allowed in the exchange field is a good idea. If you're using a Cabrillo file as an history file and there is a typo in an exchange for some reason, you're stuck. Let the user enter what he/she wants.

[w7sst]

This regular expression is used for validating the user's Sent Exchange (Edit4 near the Contest Selection dropdown in the upper right corner). This is not used to validate incoming values from a history file or future Cabrillo file. Also, MR has always restricted some restrictions on the characters when entering data into the received exchange values.

I sometimes question whether this error checking on the Sent Exchange string(s) is necessary or not. Perhaps this should be backed off and treated as a warning. After all, this check is what the simulator is sending back to the virtual Dx Stations and is not what is being sent to the user to be copied during the simulation. And perhaps that is your point - let the user send what they want (similar to log what you hear).

I notice that N1MM will restrict what is entered in the received exchange fields for ARRLDX Contest. For the domestic runner (running as w7sst), I must enter a valid Power level and for the DX Runner (running as f6/w7sst) a valid state/prov must be entered before the QSO is accepted. So perhaps all data from imported from a history or future Cabrillo file should be validated before usage during the simulation. I did notice that N1MM will notify user of an invalid state/prov entry, yet still allow user to override the error check and submit the bad state/prov value into the log. Likewise, I was able to force N1MM to access '100' was a state/prov value. I'm not suggesting that MRCE allow this, just observing what N1MM is doing.

I can certainly change this back to expect any two character sequence for state/province.

[K6OK]

Perhaps this should be backed off and treated as a warning.

Sure. I see data validation for the Edit4 ExchangeEdit textbox as a courtesy notice to the user that they might be making a mistake. If somebody wants to send "ZZ" as their state, province or power, there's no harm. It's not going out over the air, it's only a simulation.

[w7sst]

Perhaps this should be backed off and treated as a warning.

Looking at the code, I think I'll leave it as is. This regular expression is sometimes checking for all numeric characters to allow those characters to be stored in a numeric field (e.g. member numbers, age, etc.). Since we still use numeric values to store some of these fields, we should leave this in place. I think we can leave this as is for now and not make further changes.