On 27/07/2015 08:06, Laurie VK3AMA wrote:
Hi Laurie,
I have a need for the UDP Free-Text command to NOT enable the "Next"
Radio Button on TAB1. Myself and several others often queue a message
into the future, not for the next minute.
As currently implemented the UDP Free-Text command ALWAYS enables that
radio button on TAB1 despite the setting of the "Send" boolean value.
On TAB2, the radio button activation obeys the "Send" flag. I know the
radio buttons behave differently on the Tabs and that the "Send" flag
may not be appropriate, but could be used as it is only used by Tab2.
The "Send" flag is used on both tab one and tab two. My intention was to
hide the differences between tab one and tab two from the UDP message
API. Looking at it again I see that I have not achieved that in this
case. It looks like things could be resolved by a fairly simple change
but it does leave a potential ambiguity.
If I change the effect of the "Free Text" UDP command such that if tab
one is active it merely changes the current free text message unless the
"Send" flag is set, then it triggers the immediate sending of the
message (or at the start of the next transmission period if the UDP
message is received during a receive period). This action is equivalent
to typing in the "Tx5" text edit and to clicking the "Tx 5" button if
the "Send" flag is set.
In the case of tab two being active, there would be no change in
behaviour i.e. receipt of a "Free Text" UDP command shall change the
current free text message and if the "Send" flag is set, the "Free text"
radio button shall be clicked.
The net effect is that the the ability to set the "Next" radio button of
the tab one "Tx 5" message cannot be set via a UDP message. I believe
this is valid behaviour as no such behaviour is available using tab two.
The ambiguity, which has always been there, is that it is not possible
to trigger immediate sending of the current free text message as the
"Free text" UDP message always contains the message text. It occurs to
me that the ability to clear the current free text message by sending an
empty message in the UDP command is of little value so I will give this
special meaning which is to clear the message if the "Send" flag is
unset and to immediately send the current free text message if "Send" is
set. This is a little complicated but I believe will add value for some
use cases.
I have committed changes as above and made a small change to the
message_aggregator reference application so that it can exercise these
changes. The documentation of the UDP "Free text" message
(NetworkMessage.hpp) now states:
* Free Text In 9
* Id (unique key) utf8
* Text utf8
* Send bool
*
* This message allows the server to set the current free text
* message content. Sending this message with a non-empty
"Text"
* field is equivalent to typing a new message (old
contents are
* discarded) in to the WSJT-X free text message field or "Tx5"
* field (both are updated) and if the "Send" flag is set
then
* clicking the "Now" radio button for the "Tx5" field if
tab one
* is current or clicking the "Free msg" radio button if
tab two
* is current.
*
* It is the responsibility of the sender to limit the
length of
* the message text and to limit it to legal message
* characters. Despite this, it may be difficult for the
sender
* to determine the maximum message length without
reimplementing
* the complete message encoding protocol. Because of this
is may
* be better to allow any reasonable message length and
to let
* the WSJT-X application encode and possibly truncate the
actual
* on-air message.
*
* If the message text is empty the meaning of the message is
* refined to send the current free text unchanged
when the
* "Send" flag is set or to clear the current free text
when the
* "Send" flag is unset. Note that this API does not
include a
* command to determine the contents of the current free text
* message.
Bottom-line, I need the ability set or not set the radio button when
sending free-text on Tab1.
Let me know if the change allows you to implement the required
functionality in JTAlert.
Thanks.
de Laurie, VK3AMA
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
