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

[Laurie, V. <vk3...@gm...>]

Bill,

On 10/06/2016 9:17 PM, Bill Somerville wrote:
>
> 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.
>
When decodes are erased in WSJT-X, they are automatically erased in 
JTAlert, so there are no Callsigns in JTAlert to double-clickthat don't 
have a corresponding decode visible in WSJT-X.

I would have thought that your using a routine/function/method (whatever 
you call it) in the code to make the decision if a Reply Packet should 
be obeyed. Can't that function be utilised to flag the decode as "UDP 
Reply acceptable"? The decode text hasn't changed from when the decode 
packet was sent and when the Reply packet was received. I am not 
following your argument here. Rather than waiting for a reply packet to 
make the decision, have the decision already coded (via a flag) in the 
original decode packet, then when a reply is received, there is no need 
make the decision again as the reply packet already contains that 
decision, since the Reply packet contains the original UDP decode data.

What I am trying to avoid is people double-clicking a CQ call in JTAlert 
and then getting no response from WSJT-X. I have already received 
numerous support requests due perceived"broken double-click" or 
inconsistent behaviour. While some of those were due to a defect within 
JTAlert, now corrected,the majority were for decodes that WSJT-X just 
never responds to.

Ultimately what I amwanting to achieve is to *accurately* highlight a 
Callsign in JTAlert that when double-clicked will setup WSJT-X for the 
QSO. After all, there is often very little time to make the decision to 
respond to a CQ and having that further delayed because WSJT-X didn't 
respond and the user potentially trying a second time and then 
ultimately trying to locate the decode within the Activity displayseems 
unnecessary and just adds to user frustration, often left with the 
impression that the software is buggy.

de Laurie VK3AMA