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

[Black M. <mdb...@ya...>]

Well if you're going to start swapping modes you get what you deserve.
I thought the problem was WITHOUT doing such things there were some CQ patterns that you could double-click in WSJT-X and it would work...but double-clicking from JTAlert would not for some odd reason.Maybe the fixes you did to the CQ QRZ  and such fixed those edge cases?
Is there any CQ  pattern that should work in WSJT-X but not in JTAlert when it returns the decode as far as you know?
de Mike W9MDB

      From: Bill Somerville <g4...@cl...>
 To: wsj...@li... 
 Sent: Wednesday, June 15, 2016 5:05 PM
 Subject: Re: [wsjt-devel] Request: WSJT-X UDP protocol extension to identify decodes to will accept UDP reply command.
   
 On 15/06/2016 22:40, Laurie VK3AMA wrote:
  
Because without the certainty that a Decode is "UDP Reply capable", JTAlert has no reliable way of highlighting that a Callsign is double-clickable. If JTAlert highlights a Callsign as double-clickable to the end user, there is an expectation that WSJT-X will respond to that double-click. That doesn't currently happen. As a result, the end-user is left with the impression that JTAlert is broken (with a resulting increase in support emails I receive), when it is not broken, just that WSJT-X will not accept the Reply Command for that particular decode. To try and avoid this situation, my intention is to only provide a "Double-clickable indication" to the end user when the decode is known to accept the Reply Command.
 
 JTAlert needs to know programmatically that a particular decode will accept the UDP Reply Command.
 
 Trying to educate the end-user that not all CQ decodes will accept the double-click and that they need to only use the JTAlert double-click on certain decodes is not practical. Thus my desire to only indicate decodes that will accept the double-click and get the end-user into the habit, that "this type of visual indication"  will correctly setup WSJT-X, rather then the "try it and see if it works" as currently exists.
 
 I'm not sure how I can explain this any differently.
 Hi Laurie, I understand what you are asking. Let me give you an example, that you can try, that may help to explain why this is not 100% possible: 1) Select JT9+JT65 mode in WSJT-X and monitor an HF band with activity in both modes,
 2) wait until a station calls CQ,
 3) switch WSJT-X to the other mode from CQ caller,
 4) double click the CQ message. What do you expect WSJT-X to do? How can WSJT-X inform you at decode time whether a double click will get a response? This may seem a contrived case to you but it is a simple example of why the decision to respond to a double click is made at the time of the double click, not at the time of decode.
  73
 Bill
 G4WJS.
  
------------------------------------------------------------------------------
What NetFlow Analyzer can do for you? Monitors network bandwidth and traffic
patterns at an interface-level. Reveals which users, apps, and protocols are 
consuming the most bandwidth. Provides multi-vendor support for NetFlow, 
J-Flow, sFlow and other flows. Make informed decisions using capacity planning
reports. http://pubads.g.doubleclick.net/gampad/clk?id=1444514421&iu=/41014381
_______________________________________________
wsjt-devel mailing list
wsj...@li...
https://lists.sourceforge.net/lists/listinfo/wsjt-devel