[WT-support] Little help with LUA-stuff

[Bob Wilson, N6TV]

This seems like it will work OK for CW, but it still doesn't provide a
work-around for the Escape key problem when operating Phone (or RTTY),
described below and in Task #289.

I don't understand why this can't be fixed for all modes (no custom scripts
required).  You don't need an SO2R box to recreate the problem, just watch
the red RX/TX "LEDs" in the secondary radio window.

Scenario for *secondary radio*:

    F1:  $R1R1 $F1 $R2R2
INSERT:  $R1R1 $INSERT $R2R2
  PLUS:  $R1R1 $PLUS $R2R2

    F1:  CQ F6FVY F6FVY
INSERT:  $LOGGEDCALL $QSOB4 $GUESSEXCH $F2
  PLUS:  $CORRECT TU F6FVY

Set focus to secondary radio window via [CapsLock], then press Escape after
pressing F1, INSERT or PLUS, and you are stuck listening to radio 1 instead
of radio 2.

Get called by a dupe, and you are stuck listening to radio 1 instead of
radio 2.

If a message is interrupted, either by $QSOB4 or pressing Escape, the rest
of the CW/RTTY message should just be ignored, *except* for all of $R2R2
focus commands, which should still be respected.

In sum, Advanced SO2R is kind of broken right now in Win-Test:

http://flyspray.win-test.com/index.php?do=details&id=205 - QSOB4 leaves you
listening to wrong radio
http://flyspray.win-test.com/index.php?do=details&id=264 - Can't use
secondary radio to announce serial numbers on phone
(side effect of fix for task
#137<http://flyspray.win-test.com/index.php?id=137&do=details>reported
by OH2UA for Alternating CQs, now closed)
http://flyspray.win-test.com/index.php?do=details&id=289 - Escape key always
puts both ears on primary radio
(also a side effect of the fix for task #137, perhaps).

73,
Bob, N6TV

On Wed, Sep 15, 2010 at 2:11 PM, Laurent HAAS - F6FVY <f6fvy at free.fr> wrote:

> Hi Bob et al.
>
> Bob Wilson, N6TV a écrit :
>
> > Thanks, this sounds like an excellent enhancement that will definitely
> > simplify things.  QRX for Version 3 of the PSE QSY scripts after some
> > testing.
> >
> > Is there a wtKeyer:Play API that works the same way (synchronously)?
> > Ideally it wouldn't return until the message completed, or Escape halted
> > the CW.  It could then return "true" if the CW message completed, or
> > "false" if it was interrupted.
>
> If the wtKeyer:Play was working synchronously, it would block all other
> actions in the main thread of Win-Test, meaning that you couldn't even
> use the keyboard, click a window etc...
>
> But, if you want to "mimic" it, it's pretty easy.
>
> -- bPlaying.wts
>
> if (wtArg == 1) then
>   bPlaying = 1;
> else
>   bPlaying = nil;
> end;
>
> CW message :
>
> #@BPLAYING(1) BLAH BLAH BLAH #BPLAYING()
>
> -- esc.wts (assigned to the Esc key)
>
> if (wtApp:IsPostKeyProcess()) then
>   if (bPlaying ~= nil) then
>     wtApp:AlertBox("Message Interrupted");
>   end;
> else
>   return 1; -- Triggers a post key process call
> end;
>
> Of course, you can use any global variable name.
>
> Also, in a next release (maybe the next nightly build), you will be able
> to include scripts calls in the $QSOB4 variable.
>
> > Finally, I see in the wt_dev Release.txt that you have also added the
> > wtStatus API to make it possible to automate PSE QSY messages at a
> multi-op:
> >
> > - wtStatus:GetFreq(strBand[, strMode]) returns the "best" pass freq for
> > a given band and mode.
> >
> > How is "best" defined?  Same search priority as $FREQnn (R, R+, M,  and
> > M+)?  If it always goes to the PASSFREQ, that is not what I would want
> > it to do.  Most often one would pass stations to the Run frequency of
> > the Primary Run radio on that band.  Also, I don't remember how to
> > delete a PASSFREQ once it gets set.  Typing PASSFREQ and deleting the
> > frequency and press OK doesn't seem to have any effect in manual mode
> > (which is what you do when you don't have an RS-232 line available to
> > control a rig).
>
> It is defined the same way as the $FREQnn variable, only relying on the
> RUN freq. But, with the new APIs provided, you can tailor the algorithm
> as you want.
>
> Regarding the pass frequencies, I thought it was possible with the
> dialog you mentioned. I will check it - It looks like no one ever wanted
> to clear it since almost 10 years ;-)
>
> 73
>
> Larry - F6FVY
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.f5mzn.org/pipermail/support/attachments/20100915/3dc78075/attachment.htm