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:g4...@classdesign.com]
*Sent:* Sunday, May 03, 2015 9:58 AM
*To:* wsjt-devel@lists.sourceforge.net
*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:*hamapps-b...@yahoogroups.com.au
<mailto:hamapps-b...@yahoogroups.com.au>
[mailto:hamapps-b...@yahoogroups.com.au]
*Sent:* Sunday, May 03, 2015 12:18 AM
*To:* hamapps-b...@yahoogroups.com.au
<mailto:hamapps-b...@yahoogroups.com.au>
*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
wsjt-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/wsjt-devel
