He did say he's able to get rid of all file/directory accesses so that will
solve that problem.
Looks like your first stab got everything covered.
73
Mike W9MDB
From: Bill Somerville [mailto:[email protected]]
Sent: Tuesday, May 05, 2015 8:16 AM
To: [email protected]
Subject: Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
On 05/05/2015 14:06, Michael Black wrote:
Hi Mike,
Laurie said he doesn't see anything else he needs. Had to tell him Replay
was for getting the current statuses which he didn't quite make the
connection.he thought it was related to Decode again.
Do you think it might be more aptly named StatusReplay and move the
description in NetworkMessage.hpp to right below Status since they're
related?
I am surprised that there are not other bits of status info that would be
helpful, I guess since Laurie has other mechanisms in place there is little
direct benefit at the moment. The main thing as far as I am concerned is to
get rid of the contention on the file based decodes interface which is
blocking WSJT-X in its present form.
I would have thought the replay is more related to decodes than status. I
have keep the list of commands in numerical order which I think probably
makes sense for a implementer of the protocol.
I was going to revisit the documentation and note the null byte string
behaviour since it isn't documented fully in the Qt QDataStream format. I
will try and make everything a bit clearer.
73
Mike W9MDB
73
Bill
G4WJS.
From: Bill Somerville [mailto:[email protected]]
Sent: Sunday, May 03, 2015 9:58 AM
To: [email protected]
Subject: Re: [wsjt-devel] FW: UDP interface for WSJT-X control.
On 03/05/2015 15:42, Michael Black wrote:
Hi Mike,
Small bug.I tried to see how this was happening but couldn't quite figure it
out.
Seems when DXCall is empty it is initialized correctly to a 0-length string
when the INI file has it as empty.
This is expected behaviour. The Qt serialization format differentiates
between a null QString and an empty QString as documented here:
http://doc.qt.io/qt-5/datastreamformat.html . For this case I expect that
both can be interpreted as empty.
I am a bit surprised this is happening because we convert to a QByteArray of
utf8 code points before we stream the data but looking at the Qt source
reveals that QByteArray like QString sets the length to 0xffffffff for null
as well.
It may be because m_hisCall isn't initialized to anything from the INI file.
Grid might be same problem too?
As Laurie is looking at using this new interface I wonder if there is any
other status content that would be valuable to him, particularly if it
avoids any Windows cross process gymnastics to discover them?
Mike W9MDB
73
Bill
G4WJS.
From: [email protected]
[mailto:[email protected]]
Sent: Sunday, May 03, 2015 12:18 AM
To: [email protected]
Subject: Re: [HamApps-Beta] UDP interface for WSJT-X control.
Mike,
Testing WSJT-X 1.5 r5249 here and found a bug within the UDP data.
When WSJT-X first starts without a DXCall set, the UDP status packet has the
length for the DXCall set to 0xFFFFFFFF, rather than the true length which
is 0x00000000.
If I enter a character and delete it, so that the DXCall is empty, the
Status packet has the correct zero length set in the DXCall utf8 data. So
this is only a startup problem which I have coded around, but thought you
may like to pass it on as here may be other startup bogus data in the
current UDP implementation.
de Laurie VK3AMA
------------------------------------------------------------------------------
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
_______________________________________________
wsjt-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
