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.

73
Mike W9MDB

On Thu, May 28, 2015 at 11:32 AM, Bill Somerville <[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]>
> 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]
>> <[email protected]>]
>> *Sent:* Thursday, May 28, 2015 8:13 AM
>> *To:* [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
>
>
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel

Reply via email to