On 27/07/2015 11:51, Michael Black wrote:
Hi Mike.
Hmmm…looks to me like if the client sent a -1 the second tab logic
would remain the same and tab 1 would become.
if (0 == ui->tabWidget->currentIndex ()) {
ui->tx5->setCurrentText (text);
switch(send) {
case 0: ui->txrb5->click ();break;
case 1: ui->txb5->click();break;
// default value is no button click or enabling of message
}
I think the bool is just 0/1 by default in C++, isn't it? You can use
other values though and any non-0 value is true.
I have to leave in a minute and don't have the time to reverify this
common question under C++.
And yes…the client needs to know which of 3 actions they want to
do…not which tab the user is using as 1/-1 is the same action for Tab 2.
Is my logic totally hosed here?
The flaw, as I see it, is that the sender of the message has to know
which tab is active because the "send next" capability is not available
on tab two. By having it do "send now" as a substitute, if tab two is
active, you are asking that WSJT-X send a message on air unexpectedly.
My solution removes the capability of clicking the "send next" radio
buttons on tab one via the UDP command interface, this is an inevitable
consequence of hiding the tab one/two differences from the UDP
interface. I don't think this change is a serious deficiency since the
message sending application can easily orchestrate the sending of the
free text message at a time of its choosing if required, I will also
facilitate this by having the UDP "free text" command trigger sending of
the current free text message without change when the arguments are ("",
true).
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:[email protected]]
*Sent:* Monday, July 27, 2015 5:33 AM
*To:* [email protected]
*Subject:* Re: [wsjt-devel] Request: UDP change to Free-Text command
On 27/07/2015 11:30, Michael Black wrote:
Hi Mike,
"Better" is always better J-- Especially when you can satisfy
everybody's needs.
Agreed although the last part of that may be tricky.
I remember now you saying about the tab knowledge before and I seem to
remember trying to follow the logic in the code as to why that was…but
never satisfied myself. I wasn't able to see how the client request
actually got processed.
It is actioned in the signal/slot hook up at line 203 in mainwindow.cpp.
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:[email protected]]
*Sent:* Monday, July 27, 2015 5:22 AM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* Re: [wsjt-devel] Request: UDP change to Free-Text command
On 27/07/2015 10:59, Michael Black wrote:
Hi Mike,
The real solution to this is a tri-state meaning of the flag for
this. Right now it's Boolean. So make it an int and -1,0,1 --
0 and 1 have the current meaning, and -1 means don't activate
(which is the same as 0 for Tab 2 also).
Then the user can select the typical action they want from the
client. This really needs to be a user choice.
That is not a good solution as we have discussed in the past, the
problem with it is that it requires knowledge of which of tab one and
tab two is active.
I think I have a better solution, which I am testing right now, and I
will post something soon.
73
Mike W9MDB
73
Bill
G4WJS.
*From:*Laurie VK3AMA [mailto:[email protected]]
*Sent:* Monday, July 27, 2015 2:07 AM
*To:* [email protected]
<mailto:[email protected]>
*Subject:* [wsjt-devel] Request: UDP change to Free-Text command
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.
Bottom-line, I need the ability set or not set the radio button when
sending free-text on Tab1.
Thanks.
de Laurie, VK3AMA
------------------------------------------------------------------------------
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
