[WT-support] ESM functionality

[Bob Henderson]

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>

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> 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
> > 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/2981adff/attachment.htm