On 14/03/2015 15:19, Michael Black wrote:
Hi Mike,
I am trying to figure out the best way to do this. I had tried and
was successful on using readyReady but now that I think of it I had it
in a separate thread and that's not needed.
I'll go back and try that again as that is a lot more intuitive.
It takes a bit of practice to get used to the Qt asynchronous model.
Once you get the hang of it you will see that it is an excellent way of
handling multiple tasks in parallel without the complexities and hazards
of multiple threads.
readReady in the main thread is the right way to go, stick with it ;)
The example here: http://doc.qt.io/qt-5/qudpsocket.html#details
has everything you need for processing incoming UDP datagrams. For
"Server" you can safely read "MainWindow" if the processing of the
datagrams (processTheDatagram()) doesn't block.
I can ultimately see controlling all button clicks and such….just
wanted to start with the obvious one which is "Hey WSJT-X…here's a CQ
message….do your thing".
That's ambitious!
I was concerned a bit about using the activity list since there's been
discussion on when things should get cleared…so JTAlert might at some
point keep calls around after WSJT-X has cleared them giving bad behavior.
I would probably limit actions on activity to the last reported period.
I figured handling an external CQ message was more like the result of
double-clicking a Band Activity entry so was trying to repeat the
result and if I put the CQ in the RX side I know it's there.
OK, but for for now it might be best to limit the remote command to
"reply to a CQ from the station with callsign X and DF Y". This is
probably the most useful remote command that JTAlert can utilize i.e.
initiate a QSO from an alert.
I'll play with it a bit and see what works…
Thanks…
Mike W9MDB
73
Bill
G4WJS.
*From:*Bill Somerville [mailto:g4...@classdesign.com]
*Sent:* Saturday, March 14, 2015 10:09 AM
*To:* wsjt-devel@lists.sourceforge.net
*Subject:* Re: [wsjt-devel] UDP Server
Hi Mike,
I did note your comments on the Hamapps list related to this.
First off it would help to have a clear idea of what remote control
features you are considering. I ask because the way that the activity
windows are currently implemented may not be very amenable what you
might wish to do.
With respect to processing incoming UDP datagrams, you have two
choices, either asynchronous or synchronous. You might choose
synchronous is there is likely to be long running activity as a result
of receiving a datagram. In the synchronous case you would need to
have a thread available and bind the UDP socket in that thread so that
any activity does not block the GUI thread.
The asynchronous approach is normally harder to implement but Qt
actually makes it the easiest and most natural approach. You bind the
UDP socket in the main GUI thread and connect the readReady signal to
a suitable slot. In that slot you process the incoming datagrams. The
signal will only be emitted when there is a pending UDP datagram
awaiting processing. Just be sure that slot that handles the readReady
signal does not block. The BIG advantage of asynchronous processing is
that it is thread safe since everything runs in the main thread.
Your doCall mechanism is duplicating what Qt does for you already when
it emits the readReady signal.
Beware reading strings from a socket, sockets are byte oriented and
the QString class is unicode, you need to define a protocol for the on
the wire transfer - utf8 for strings is usually good ASCII may be
acceptable - and translate as necessary.
Looks to me like you are attempting to receive a decoded message and
trigger a double click on that message, you may find it easier to
receive a callsign+DF pair and search for that in the activity list.
You should be starting with a protocol and defined messages that
WSJT-X is willing to accept. Seems to me that you are starting with an
implementation perhaps without thinking through how it is going to
work for the user.
HTH
73
Bill
G4WJS.
On 14/03/2015 14:40, Michael Black wrote:
After some communication with Laurie on JTAlert we have started down the
path of integrating WSJT-X a bit more.
The idea is that WSJT-X should have a UDPServer that can receive commands to
do things so, for example, one could double-click on a JTAlert entry and it
could command WSJT-X to do its thing.
To this end I started coding one but am having QT class problems that are
befuddling me and was hoping someone (Bill?) could assist.
So far this implementation is intended to just take a "CQ" decoded message
and put it in the "Rx Frequency" window. Then I was going to add the
double-click action once the first was working and stable.
I got this somewhat working but debugging complained about sending signals
when I just threaded a function inside then mainwindow.cpp plus gui stuff
isn't thread safe.
So I made the udp server a separate class and started trying slots/signals.
But now connecting the slot/signal burps on compiling and I can't quite
figure out the magic incantation to make it happy.
This is the line it complains about on MainWindow::doCall
connect(m_UDPServer,&UDPServer::on_doCall,this,&MainWindow::doCall);
doCall is declared as a public slot in mainwindow.h and defined in
mainwindow.cpp
C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h: In instantiation of
'static QMetaObject::Connection QObject::connect(const type
name QtPrivate::FunctionPointer<Func>::Object*, Func1, const typename
QtPrivate::FunctionPointer<Func2>::Object*, Func2, Qt::Connection
Type) [with Func1 = void (UDPServer::*)(DecodedText); Func2 = void
(MainWindow::*)(DecodedText); typename QtPrivate::FunctionPointer<Fu
nc>::Object = UDPServer; typename QtPrivate::FunctionPointer<Func2>::Object
= MainWindow]':
C:\JTSDK\src\wsjtx\mainwindow.cpp:461:69: required from here
C:/JTSDK/qt5/5.2.1/mingw48_32/include/QtCore/qobject.h:222:9: error: static
assertion failed: No Q_OBJECT in the class with the signal
Q_STATIC_ASSERT_X(QtPrivate::HasQ_OBJECT_Macro<typename
SignalType::Object>::Value,
^
Here's a UDP client to work with it that just cycles through a few CQ
messages. All being done on port 5001 right now.
https://www.dropbox.com/s/pp5z7nqrtdeug9a/UDPClient.exe?dl=0
Mike W9MDB
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website,
sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for
all
things parallel software development, from weekly thought leadership blogs
to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now.http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net <mailto:wsjt-devel@lists.sourceforge.net>
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
------------------------------------------------------------------------------
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
_______________________________________________
wsjt-devel mailing list
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
