Hi again Mike,
related to this I have my new processing of decoded messages changes
ready for commit. I was testing them but I have done enough to justify
committing them to the development branch.
They are going to collide with your UDP receiver changes so I will
commit them now, you probably want to update now before you get too
involved in changing mainwindow.cpp otherwise the eventual merge is
going to be complex.
I will commit in a few minutes.
73
Bill
G4WJS.
On 14/03/2015 15:08, Bill Somerville wrote:
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
