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.
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".
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 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.
I'll play with it a bit and see what works.
Thanks.
Mike W9MDB
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
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
