Re: [wsjt-devel] Request: WSJT-X UDP protocol extension to identify decodes to will accept UDP reply command.

[Bill S. <g4...@cl...>]

On 10/06/2016 05:10, Laurie, VK3AMA wrote:
> I propose that the UDP protocol, specifically the decode packet, be 
> extended to include a Boolean flag that identifies if the decode will 
> respond to a UDP Reply command.
>
> Not all CQ/QRZ decodes are supported by the UDP Replycommand and it 
> would be beneficial if those decodes are easily identified (within the 
> decode packet) as not being acceptable by WSJT-X, rather than 
> performing exception tests or analysis of the decode string 
> structureas is currently neededto identify these unsuitable decodes.

Hi Laurie,

that is not very easy, for example if the decodes are erased then they 
are no longer capable of being replied. Bottom line is that the decision 
to react to a decode on double click (or UDP reply message) is made at 
the time it is done, not when the decode is received.

Yesterday I committed a change that will make the highlighting and the 
response to UDP reply messages more consistent. Other than that you 
should just send the reply packets and if WSJT-X does not respond then 
it should be safe to assume that double clicking the same decode in 
WSJT-X would not do anything either, with the exception that only 
general call *standard messages* will be responded to via the UDP reply 
message. No one to my knowledge has complained that double clicking some 
decodes in WSJT-X does not cause WSJT-X to react.

If JTAlert users are finding that a general call message is not being 
responded to then they must put forward a case for making them standard 
messages. That is a very difficult case to make because we cannot change 
the protocol without major disruption. There are edge cases like the 
possible use of the E9 prefixes for more flexible CQ calls, this is 
where change should be requested rather than expecting WSJT-X guess the 
intent of various free text messages.

73
Bill
G4WJS.