[WT-support] ESM functionality

[Bob Henderson]

Steve

Only in my dreams would my gun be big enough to anticipate better than 1 in
2 mults called would respond first call.  So, 'big gun' functionality is not
too much of a priority here.

However, were Laurent & Olivier to agree to implement cursor/field
addressing, 'big gun' functionality would arise by default.  I believe it
should only be necessary to add $SpaceBar to the S&P F4 message to achieve
it.

Bob, 5B4AGN

2009/7/14 Steve London <n2icarrl at gmail.com>

As an N1MM Logger user, seeing this discussion is like deja vu. The N1MM
> users
> could never reach a clear consensus on the "correct" operation of ESM in
> S&P
> mode. The solution in N1MM was to add the so-called "big gun switch"
> configuration checkbox. When the big gun switch is "on", the first time you
> hit
> Enter, it sends your call. The next time you hit Enter, it sends the
> exchange.
> If you need to send your call again before sending the exchange, it
> requires
> hitting the "mycall" function key. When the big gun switch is "off",
> hitting
> Enter will continue to send your call until you use the spacebar to move
> the
> cursor into the exchange field. At that point, hitting Enter will send the
> exchange.
>
> Laurent and Olivier, save your self endless grief and bandwidth on this
> issue
> and add a "big gun switch" to Win-Test.
>
> 73,
> Steve, N2IC
>
> Bob Henderson wrote:
> > Hi Philippe
> >
> > No offence taken but I'd like to make a correction to your understanding.
>  I
> > make suggestions NOT demands.
> >
> > I'm puzzled by your comment.  " IMHO, I want to know, every time I press
> the
> > 'enter' key, what will be output."  This is exactly my point No. 2. It is
> not
> > possible to know from looking at the screen what will be output as it is
> > dependent upon number of 'enter' key presses not the cursor position.
> >
> > The change I have requested would ensure the operator can always know
> what
> > will happen next by checking the cursor position on the screen. This
> would be
> > true in both RUN and S&P modes.
> >
> > I disagree that ESM cannot be useful in S&P.  I also disagree that it is
> > desirable to have to abandon it when repeats are requested.
> >
> > With the scheme I have described 99%+ Qs can be handled with use of only
> the
> > 'enter' key and Space Bar.  With the current arrangement the % of Qs
> which
> > can be handled this way is significantly lower.
> >
> > I firmly believe my suggestion would make for a superior ESM
> implementation.
> > I also accept if I am the only one that thinks so it would make no sense
> to
> > implement the change.
> >
> > FWIW
> >
> > Bob, 5B4AGN
> >
> > 2009/7/14 F6IFY Philippe <f6ify at free.fr <mailto:f6ify at free.fr>>
> >
> > Hi Bob and all the list,
> >
> > No offense Bob, but I hope Olivier and Larry will not follow your demand.
> > IMHO, I want to know, every time I press the "enter" Key, what will be
> the
> > output. So when I have a doubt I wish to be able to use the Fx keys to be
> > sure not sending the wrong message.
> >
> > So, I hope Larry will keep the ESM as simple and stupid as it is for the
> > moment. IMHO, ESM is useful only in Run mode when all is "nominal"
> > (regular?).
> >
> > I have used ESM intensively on others softwares, and I think the Larry's
> > design is by far the best.
> >
> > 73 Philippe - F6IFY
> >
> > ----- "Bob Henderson" <bob at 5b4agn.net <mailto:bob at 5b4agn.net>> a écrit :
> >
> >> Dear Olivier and Laurent
> >>
> >>
> >> I realise you have only just implemented ESM in V4 but I wonder
> > if you
> >> might be prepared to consider a change to its functionality to
> accommodate
> >> cursor addressing?
> >>
> >> The current functionality has two clear disadvantages IMHO:
> >>
> >> 1. When a QSO does not follow the usual format it is necessary to revert
> to
> >> F keys to avoid inappropriate responses. (E.g a request for repeat of
> >> exchange.)
> >>
> >> 2. The operator cannot tell from looking at the screen what will happen
> >> when he next presses return.
> >>
> >> If ESM was re-coded such that message sent and logging action taken were
> >> dependent upon which field the cursor is in, together with the content
> of
> >> that field, these disadvantages would be overcome.
> >>
> >> I believe the following behaviour would provide a useful improvement.
> >>
> >> RUN
> >>
> >> Cursor in empty Call field - return = F4 Cursor & Call in Call field -
> >> return = Insert Cursor in Exchange field - return = +
> >>
> >> S&P
> >>
> >> Cursor in empty Call field - return = F4 Cursor & Call in Call field -
> >> return = F4 Cursor in Exchange field - return = Insert
> >>
> >> A useful addition to the message variables might be something
> > like $>.
> >> This variable added to the end of the RUN Insert message would
> >> automatically advance the cursor to the Exchange field. The Space Bar
> >> toggles between Call & Exchange fields, so it would only be necessary to
> >> press the Space Bar before Return on those occasions where a
> > repeat
> >> was requested.
> >>
> >> Thank you for your consideration.
> >>
> >> Bob, 5B4AGN, P3F
> >>
> >>
> >> _______________________________________________ Support mailing list
> >> Support at win-test.com <mailto:Support at win-test.com>
> >> http://www.f5mzn.org/cgi-bin/mailman/listinfo/support
> > _______________________________________________ Support mailing list
> > Support at win-test.com <mailto:Support at win-test.com>
> > http://www.f5mzn.org/cgi-bin/mailman/listinfo/support
> >
> >
> >
> >
> > ------------------------------------------------------------------------
> >
> > _______________________________________________ Support mailing list
> > Support at win-test.com
> http://www.f5mzn.org/cgi-bin/mailman/listinfo/support
> _______________________________________________
> Support mailing list
> Support at win-test.com
> http://www.f5mzn.org/cgi-bin/mailman/listinfo/support
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.f5mzn.org/pipermail/support/attachments/20090714/c8071e98/attachment-0001.htm