Updated ways to implement a user defined hardware controller which is
executed just after band changes during WSPR band hopping operation.
Allows the user_hardware executable to be located in any directory on
the PATH environment variable. On Windows any file extension listed on
the PATHEXT environment variable may be used, the first match using
PATH and PATHEXT will be executed. On Windows this is achieved by
using CMD.EXE with a '/C' command line flag, i.e. the user's hardware
controller is executed like this:
CMD.EXE /C user_hardware nn
where 'nn' is the new band as an integer in meters.
On non-Windows systems the user's executable will be run if it is
found on the directories specified by the PATH environment variable,
and it is executable, i.e. it is equivalent to something like:
/bin/sh -c user_hardware nn
where 'nn' is the new band as an integer in meters.
In all cases the user_hardware controller should exit with a zero
status, otherwise it have been deemed to have failed. On Windows avoid
an exit status of one as that is utilized by CMD.EXE to indicate the
file was not found, which WSJT-X ignores silently.
This change means the prior need to put the user's hardware controller
into a WSJT-X installation directory like /usr/local/bin or
C:\WSJT\wsjtx\bin is no longer necessary.
When passing the 'Highlight last' parameter as true occasional matches
in prior periods could be incorrectly highlighted. This fix should
also improve performance when there is a large decode history, and
highlight request for a new callsign is received.
Using a Highlight Callsign UDP message with `Highlight last` false and
specifying both f/g and b/g colours as invalid now resets the
highlighting on any matching callsign, as well as removing the decode
highlighting internal record.
These go wrong too easily with l10n, this ensures the right menu
actions are treated specially on macOS and moved to their "normal"
place on the global system menu.
The Highlight Callsign (13) UDP message now operates in a slightly
different way. The "Highlight last" field, when true valued, causes
all instances of the specified callsign to be highlighted in the
decoding period. This allows external applications to highlight DX
callsigns even when multiple stations are calling them. Before this
was unlikely to work since the external application would have to
respond to Decode (2) UDP messages exceedingly quickly to guarantee
successful highlighting before another decode with the same DX call
was printed. There should be no changes required to external
applications acting as servers to the WSJT-X UDP Message Protocol,
although using the version of the Highlight Callsign (13) with
"Highlight last" should not be required for adhoc callsign
highlighting. It should be reserved for commonly recurring targets and
limited to no more than 100 active highlighting requests at any one
time, otherwise there may be performance impacts on WSJT-X.
This could make help text windows bigger than the screen, if we want
to go there then using a QLabel sub-class will need to change,
probably by using a read-only QTextEdit instead as that provides
scroll bars. Maybe consider a multi-column table for the contents as
an alternative to scroll bars.
