[WT-support] WT Station Type changing inadvertently

[Olof Lundberg]

Thanks Bob, of course I take the Wiki literally, if it says that Alt-Y
changes the current QSO I believe it. But what you really are saying is that
the Wiki is wrong, Alt-Y toggles the setting for this QSO and onwards. Fine
but then the Wiki should be changed.

 

OK, I understand that there might be a reason to swap RUN1/RUN2 if you go
mad on QSYs but I have had this happen unintentionally last weekend and also
seen it happen on earlier occasions w/o understanding why so I think I'd
like to disable those keystrokes from now on in my configurations and then
rather rely on typing RUN1/RUN2 as and if required.

 

I agree with you, make "Sticky" the default but I also think the Alt-Y and
Ctrl-F3 should be abandoned - we are talking QSYs over a 60-minute period so
the need to change should not be that frequent and typing RUN1/RUN2 should
not be too onerous.


Anyhow, not a big deal now that I understand what is going on (and the Wiki
will hopefully be corrected?)

 

73 and you are a star Bob, best support in the ham radio sphere

Olof G0CKV M5E

 

 

 

 

 

From: support-bounces at f5mzn.org [mailto:support-bounces at f5mzn.org] On Behalf
Of Bob Wilson, N6TV
Sent: 20 March 2014 23:21
To: Win-Test Reflector
Subject: Re: [WT-support] WT Station Type changing inadvertently

 

On Thu, Mar 20, 2014 at 3:43 PM, Olof Lundberg <olof at rowanhouse.com> wrote:

During RDXC I had RUN2 on three occasions switch to calling itself RUN1. I
caught it early so it was easy to switch back and correct. The station setup
was all in a stable configuration with no RFI and such; no reboots or
restarts during the contest and 'sticky setting' was ticked. I wonder if
this might have happened by RUN2 accidentally hitting Alt-Y or Ctrl-F3? But
the Wiki says that these keyboard commands should only change the current
QSO - it doesn't say that the setting would be toggled. Is the manual wrong
or is there something else going on?

 

I think you may be taking the wording in the Wiki a little too literally,
but I can try to make it more clear since you found it confusing. 

 

A simple test reveals that pressing Alt-Y or Ctrl-F3 on the last line of the
logging window changes the station type exactly the same as typing RUN1 or
RUN2 [Enter], or using the menu equivalent: Commands -> Station Type -> Run
1 or Run 2.  So yes, the new station type applies to the current logging
line, even if it is the last line in the logging window (the empty one).  If
done with the cursor on the last line, any new QSOs you log on that computer
after that will use the same (new) station type.

 

I don't see any reason to change it.  It's faster than using the menu or
typing the text commands, if you change station type often.

 

 One thought would be to reassign those keys to something innocent

 

DEFINEKEYS can certainly be used to map Alt-Y and Ctrl-F3 to "!"
(exclamation point or similar, a key that is ignored), so that the function
is effectively disabled and nothing happens when you hit them accidentally.

 

I can't see any reason to change station type in-flight?

 

Station type is often changed if one station is nearing the band change
limit, and the other has band changes to spare.  The very useful "Sticky"
setting in the same menu is relatively new, so it is still common that
people need a way to quickly fix a bunch of QSOs that were accidentally
logged with the wrong station type.  This often happens after a restart.

 

For those who are unaware, "Sticky" means the station type will stay the
same (RUN1 or RUN2 for M/2, RUN or MULT for M/S), even if you restart or
reboot.  Without that sticky setting checked, Win-Test always changes the
station type back to RUN1 or RUN when it restarts, which often causes much
headache.

 

I really think "Sticky" should be the Win-Test default whenever you create a
new multi-2 or multi-single log, but I don't think it is.  So you still need
Alt-Y and Ctrl-F3 to fix things quickly.




73,

Bob, N6TV

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.f5mzn.org/pipermail/support/attachments/20140320/c7e694da/attachment-0001.html>