Tree can trump any of the following idle speculation...
Without being the actual developer, I believe this "opportunity" stems
from the program's architecture. Because the logs and exchange data are
kept on disk and not in memory, it's a lot harder to make incremental
changes in them while logging. This also saves on memory and makes
program crashes much less catastrophic.
Perhaps an intermediate solution would be to make an on-the-fly file that
tracks changes from defaults during the current contest. It would require
an extra disk-file access for each QSO. At the end of the contest,
changes could be folded back into the appropriate data base under operator
control.
73, Ward/Ed/Homer/Snoop, N0AX
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
Feature Wishlist: http://web.jzap.com/n6tr/trwish.html
|