On 14/06/2016 23:05, Laurie VK3AMA wrote: > Since the only reliable (?) method for identifying WSJT-X decodes that > will accept the UDP Reply Command is the "Try it and wait to see if > WSJT-X responds" technique. I will be changing JTAlert behaviour with > respect to the UDP Reply command, AKA double-click a CQing Callsign. > > From the next JTAlert release, only standard format CQ decodes, "CQ > Callsign Grid" will be highlighted in JTAlert as double-clickable. All > other CQ style decodes will no longer accept the double-click or be > highlighted (green rectangle drawn around the callsign) as accepting a > double-click.
Hi Laurie, I'm not sure I understand yet why JTAlert has to be so certain about double-click responses, WSJT-X isn't. Also please review the behaviour of the latest development version as I did make changes to rationalize some of the more glaring omissions in the highlighting and double-click behaviour of general call messages. In particular: QRZ <callsign> [<grid>] CQDX <callsign> [<grid>] CQ DX <callsign> [<grid>] should be treated the same as: CQ <callsign> [<grid>] now. If the <callsign> word above is not acceptable to WSJT-X as a valid callsign, type1 compound callsign or type 2 compound callsign then WSJT-X cannot be expected to respond sensibly to a request to reply to that message. 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 [email protected] https://lists.sourceforge.net/lists/listinfo/wsjt-devel
