On 28/05/2015 17:54, Michael Black wrote:
Hi Mike,
I think the flag sounds like the solution.
Laurie said he's not tab 2 guy -- but if you're insert text from
JTAlert macros he want to give the user an option to not transmit
immediately.
OK, I have added a flag to determine if the change free text UDP message
should just change the message text (clear) or change the text and send
the message ASAP (set).
The message_aggregator reference application exercises the new
functionality. Typing into its free text box causes the free text
message in WSJT-X to change too and pressing RETURN or moving focus away
causes the free text message to be sent by WSJT-X ASAP.
This now makes the behaviour in tab 1 and tab 2 identical when receiving
the free text UDP message and servers should be able to both give visual
feed back via the WSJT-X free text edit field and choose if and when the
message gets sent by WSJT-X.
73
Mike W9MDB
73
Bill
G4WJS.
On Thu, May 28, 2015 at 11:32 AM, Bill Somerville
<[email protected] <mailto:[email protected]>> wrote:
On 28/05/2015 17:05, Michael Black wrote:
Hi Mike,
I should've mentioned he wants to be able to queue up a message
for the next transmit period. You can always just click the
button if you want immediate in that case.
That's not the way tab 2 works. The options are:
Tab 1:
1) change the message
2) select the message to send in the next Tx period
3) send the message ASAP
Tab 2:
4) change the message
5) send the message as soon as possible
The current behaviour of the UDP free text message is (1) + (2) if
tab 1 is current and (4) + (5) if tab 2 is current.
We could add a flag to the message that changes the tab 1 action
to (1) + (3) which makes it effectively the same as the action on
tab 2 but there is not really a way to make tab 2 send the message
in the next Tx period rather than ASAP.
Given that Laurie only had access to the UI controls before the
UDP option I wonder how he gets what he is asking for now? I can
see that he could change the message text and click the radio
button later once the current Tx has finished to get the desired
effect.
If it is just a case of providing user feedback that something is
happening then perhaps the following might help:
UDP free text message contains a new message and a flag, if the
flag is clear only the message gets changed, if the flag is set
then the message is changed AND the action required to send the
message ASAP is taken (click Tx5 button on tab 1 or check the Free
text radio button on tab 2).
73
Mike W9MDB
73
Bill
G4WJS.
On Thu, May 28, 2015 at 10:50 AM, Bill Somerville
<[email protected] <mailto:[email protected]>> wrote:
On 28/05/2015 14:53, Michael Black wrote:
Hi Mike,
I'm using the dummy device…not sure if that makes a
difference…can't imagine why it should.
Yes that's fine, I do that often when testing, it is also
handy to have two instances of WSJT-X running using the
stereo mix device of your system sound card as output
(assuming your sound drivers support stereo mix); that way
you can have QSOs off line to test the software.
This is 1.5 r5394
Start WSJTX and Aggregator.
Start transmitting a message with Tab 2 visible.
Send free text
WSJTX-1.5 puts the free text in Tab 2 and changes the Tx and
Last Tx to the new text even though tx time is well beyond
25 seconds.
1.6.0 doesn’t do it. 1.6.0 puts the text in tab2 but
doesn't change either Tx message.
And here's a video showing it happening.
https://www.dropbox.com/s/0o3bpqqt7tbdn0p/WSJTX.avi?dl=0
I can't quite see how this is all triggering in the code
(maybe not enough caffeine this morning) to debug it.
Ok what is happening isn't quite as you describe it. The
incoming free text message UDP trigger is calling the click()
slot of the tab 2 free text radio button. This only generates
the button toggled() signal (which is being used to process
button activity) when the button is not checked, so when
multiple free text message triggers are received only the
first triggers a message change while transmitting. This
behaviour is the same in both v1.5 and the trunk neither
version is time in period sensitive, it is simply the
consequence of "clicking" a radio button that is already checked.
I have committed a change to the trunk that makes the tab 2
Gen/Free text radio buttons active even if they are already
checked so if the message text is changed while transmitting
clicking the radio button next to the edit field will always
change the message being transmitted.
If this is Ok with everyone I will merge it into the v1.5 branch.
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:[email protected]]
*Sent:* Thursday, May 28, 2015 8:13 AM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [wsjt-devel] 1.5 Free Text UDP Message
On 28/05/2015 13:50, Michael Black wrote:
Hi Mike,
Laurie noticed that if you are using 1.5 and send free
text it enables tab 2.
I am not able to reproduce this behaviour. Can you reduce a
test case down to a minimum set of steps using WSJT-X and
message_aggregator?
I tested and that's what happens on 1.5 but not on 1.6. On
1.6 tab 2 isn't touched at all.
I assume 1.6 behavior is the desired behavior?
There are some potential issues that need resolving in v1.6
due to the extra modes and tabs but yes I would expect
loading the free text message to only effect the currently
visible tab in v1.5.
73
Mike W9MDB
73
Bill
G4WJS.
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
