I spent some time last night trying to reproduce the problems reported
to the reflector by N7DR. I did find some problems, although I don't
know for sure if I was able to reproduce the problem he had.
Most of what I found was cosmetic. The little spinning arrow had some
bugs in it which would make it stop during much of the process - which
might make you think things were stuck.
Also, there were some ugly formtting things with text flowing off of
the top of the screen (Overwrite menu). I also thought for a short
time that I needed to have a way to specify a cursor position to
start looking for data, and then ignore a programmable number of
data entries starting at that position. Turns out the SS exchange
right hand justifies the serial number, so the QTH is in the same
place all of the time. I added that feature anyway because it probably
is needed for some other application (i.e. importing SS exchanges from
another program).
At any rate - if you think you have had the same problems as N7DR,
you are welcome to try a beta version of POST and see if the changes
I have made fixes the problem. It is available via e-mail, or I can
put it on an ftp site if you want.
Otherwise, it will be included in the official Dayton release package
which will probably be released sometime before Dayton.
In other news, I spent a large percentage of the weekend working on the
packet stuff. There really won't be many changes to how it works that
the eye can see - but it is now an object (as in object orientated
programming). Since the packet stuff started as a small afterthought,
and then continued to grow over the years, it was starting to look
overwhelming to deal with. There were pieces of it hiding around in
the 20 some odd files that make up TR.
Having all of the procedures in one place has allowed me to better
understand how it all works, and even clean things up some. I did
fix the problem of a short line appearing in you activate the control-B
window in the middle of a line coming from the TNC. I also found that
I was sending packet messages to the network twice (once for the old
function of putting the spot into the Control-U/Band Map and once
for the newer packet display feature). The Control-U menu had a bug
in it as well where it would often have some garbage in it. This stuff
is all fixed for the next release.
It is also nice to report that NOBODY has reported any kind of runtime
error with packet for a very long time (over a year?).
For those who were hoping for more packet features to be added, this is
still good news as the new structure will make it possible to add new
things in the future without taxing my brain too much. I am thinking
about how to process QSX info.
Oh - the packet spot display now says something like:
W3LPL says 4U1ITU is on 7057.2 QSX 7210 - N6TR op
So you are finally seeing all of the information in the packet spot.
Do you know what all of this activity means? It means 160 conditions
are sucko.
73 Tree N6TR
tree@contesting.com
--
FAQ on WWW: http://www.contesting.com/trlogfaq.html
Submissions: trlog@contesting.com
Administrative requests: trlog-REQUEST@contesting.com
Problems: owner-trlog@contesting.com
|