Bill, I read your lengthy and detailed replies. Thanks for that.
You said... > I suggest that you should not filter double click requests but if > WSJT-X does not respond to a UDP reply request then instead ask > JTAlert users to try double clicking the same decode in WSJT-X. This is hardly practicable. If a user gets into the habit of double-clicking a Callsign in JTAlert and the decode is shown within WSJT-X as green for a CQ decode, they should expect that WSJT-X should respond if they double-click in JTAlert. To prevent the user from double-clicking a CQ Callsign in JTAlert to which WSJT-X will not respond, I will need to provide an alternate means of identifying those eligible Callsign to the end user. What is needed is a way for JTAlert to definitively know that the CQ decode in WSJT-X will respond to the UDP reply command. My proposal, that avoids doing regex checks or exception testing against decode string formats, is to have the UDP protocol extended to include a simple boolean flag in the decode packet to indicate that this decode will respond to a UDP "reply" command. This would seem the easiest implementation and is future proof if WSJT-X changes its handling of free-form CQs and CQ coloring. de Laurie VK3AMA ------------------------------------------------------------------------------ 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. https://ad.doubleclick.net/ddm/clk/305295220;132659582;e _______________________________________________ wsjt-devel mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
