<div class="gmail_quote">On Tue, Nov 30, 2010 at 12:10 PM, Tõnno Vähk <span dir="ltr"><<a href="mailto:Tonno.Vahk@gafm.ee">Tonno.Vahk@gafm.ee</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
2. Confirm speed jump issues with MK2R+/MKII and WT with Winkey keying. We use +++/--- stuff a lot and also separate speeds for WT and paddle. So asking for trouble as I understand. Also, I guess, when message is aborted after ++++ has been run but ---- not yet the speed might stay high? I did not actually test it again now.<br>
</blockquote><div><br>Could using the paddle to halt CW cause this problem if it happens at just the right moment, between the "++" and the "--" perhaps?<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
3. A serious issue with $CORRECT. It seems that when the callsign field is empty at the time when e.g. a message of $CORRECT TU ES9C is run the $CORRECT send some totally wrong old callsign.</blockquote><div><br>I have seen this issue with WT 3, but I have not been seeing it in the newer versions of WT 4. It certainly behaves as if a memory overwrite somewhere in Win-Test is writing random characters to the $CORRECT message buffer at unpredictable times, perhaps if callsigns are being rapidly entered and corrected by other computers in the network. As a single op with one computer, I thought it was fixed.<br>
<br>Maybe a code change could clear this buffer every time the call is unchanged, even the code thinks thinks that the $CORRECT buffer should already be clear.<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
Sometimes a call worked tens of QSOs ago.</blockquote><div><br>Yes, or part of one. It is really hard to reproduce, which is why I think it is a random memory overwrite. It may also have something to do with network activity, really not sure.<br>
<br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">4. I tried the Download Files through the Network command for the first time after the contest to pull all the logs to one computer. It does not work. Did not matter which networked PC I tried the message came up: "transfer canceled. Reason: Unzip: can't open file 'C\Doc.\Temp\WT_EA.tmp'". What is wrong?<br>
</blockquote><div><br>Does the file actually exist? Is there anything new in that directory? Is the full name of the file:<br><br><div style="margin-left: 40px;">C:\Documents and Settings\<i>userid</i>\Local Settings\Temp\WT_EA.tmp <br>
</div><br>or does it display as C:\Doc.\Temp\WT_EA.tmp" in the message? Can you send a screen shot?<br><br>Do you have a program or batch file called Unzip on your PC that you can run from the command line?<br><br>
</div>
<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
5. I had 6 computers in network and the scores were different on all of them by the end!! That is real strange. WT has been usually very good on this and we don't delete QSOs.</blockquote><div><br>Were the QSO counts off, or perhaps did some computers use CTY_WT.DAT and others CTY_WT_MOD.DAT, or maybe different versions of these files? This is the first report I have seen. It is extremely rare for Win-Test to have missing QSOs accross the network, even if a computer is temporarily down or rebooted. What are the QSO totals on each computer, including dupes?<br>
<br>What version of Win-Test was running on all computers, 4.6 ?<br> <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
7. Another very small but strange issue: We had INSERT message programmed as: ++ $LOGGEDCALL--^^$SPACEBAR $GUESSEXCH $F2. In order to get the speed change for LOGGEDCALL to work a SPACE had to be entered before it!! Otherwise the ++ and -- had no effect. This is really akward. It took a while for us to figure this out. This is not the case with other messages and for example ++$CORRECT-- syntax.<br>
</blockquote><div><br>I can't replicate this problem using LPT keying. Have not tried it with a Winkey. Maybe there was something in the $F1 message or PLUS message or $F2 message? Did your F1 message end with ++TEST-- or a script call like #CLEARRIT?<br>
<br>I assume you were not using the secondary radio window at all.<br><br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
8. Another small issue. $GRABPARTNER does not trigger AUTOSEND but ALT-SPACE does. One pulls the callsign from the first line in the Stack in the Partner window, the other from the real time field in the Partner window. Can you make them the same so that inserting call with ALT-SPACE would also not trigger AUTOSEND? Because when it does then it is not possible to create a Tail End script/message which would allow toggling AUTOSEND ON/OFF during the contest like it is possible with GRABPARTNER.<br>
</blockquote><div><br>I agree that calls grabbed from the real time partner window with Alt-Space, or the activation of $SPACEBAR, should not trigger autosending.<br><br>73,<br>Bob, N6TV<br></div></div>