Some :XXX function do not work as expected

[zcsahok]

• :CFG/:SET does no reload configuration as if it is done at program start

  • commenting out/removing some configs (just to name a few: SEND_DE, NOB4, CONTEST_MODE, MINITEST) has no effect
    • test: have SEND_DE in config, comment it out, reload, SEND_DE is still in effect
  • changes of some configs (notably hamlib and cluster) are not applied
    • test: change the cluster host, reload, still connects the original one
  • network errors after reload
    • test: define other nodes in config, start program, reload config without changing it, wait, "LAN: send problem...!"
  • erroneous config file
    • test: make a typo while in :CFG, parsing stops halfway the file, program is in an undefined state
  • there is no way to edit the rule file even though it also contains configs

• Values changed via :MESsage/:SHOrt/:LONg/:CONtest commands are not persisted
  They only affect the current session.
  Changes are lost after reloading configs or restarting the program.
  Either
  1. fix it so that values are persisted (very hard IMO)
  2. warn the user about this, but at least document it (easy)
  3. remove them (very easy)

• :TRX does not reconnect to the rig
  If the connection is lost due to RFI or a network outage there is no other way
  to reconnect other than restarting the program.
  One would expect that issuing :TRX twice (rig control off/on) would solve the problem, but it does not.

[dl1jbe]

Thanks for the thorough listing of the problems with the :CFG/:SET command.

As the code works now it is not quite easy to change without heavy changes in a lot of places.

There was also a request on the mailing list some time ago to work towards a possibility to prepare the config from inside TLF maybe with a menu like system.

Both looks like we need a system which works as follows:

• During start read in all parameters set in config files (prepared in advance or stored during last stop of TLf).
• Allow setting the parameters (including the ones which are now non-persistend) via a menu-like system. That has to be done so that changes will immediately effective.
• Storing ALL parameters at exit of TLF (or/and after each change).

Maybe we should discuss these problem in the suggested (see issue #234) switch towards a new TLF-2.x.x.