Request: Add Send Method

[barrykelman]

I've written a small Windows application using the WsjtxUpdLib to monitor received messages from WSJTX, show outstanding CQs with those from not-previously-worked callers highlighted, and do the logging to QRZ, TQSL, and LoTW on QSO completion (essentially the Gridtracker feature subset I really use, using less screen real estate and memory). The one feature that isn't supported by the current WsjtxUpdLib codebase is the reply on selecting a caller from the list (via a WsJtx Reply datagram); all that is needed in WsjtxUpdLib is a Send() method in the WsjtxClient class, as follows:
public void Send(byte[] datagram, IPEndPoint from)
{
udpClient.Send(datagram, datagram.Length, from);
}
Would it be possible to add this method?

Thanx & 73
Barry W7BIK

[M0LTE]

Hi Barry
Would you want to take a byte array as the input, or would you want to leverage the library to construct the message for you based on parameters?
Else everyone has to implement their own code to construct the byte array…
Cheers
Tom

[barrykelman]

Hi Tom,
Yes, excellent point that the library should include the code to generate the Reply datagram, but I would think it belongs in a separate method in the ReplyMessage object, rather than including it in the Send() method in the WsjtxClient object. That way the Send() method stays flexible, so some future developer can use it for other message types when adding new functionality. Here's what I've got working today:
public static byte[] GenerateReply(DecodeMessage decodeMessage)
{
byte[] decodeDg = decodeMessage.Datagram;
byte[] replyDg = new byte[decodeDg.Length - 1];
for (int i = 0; i < 11; i++)
{
replyDg[i] = decodeDg[i];
}
replyDg[11] = 4;
for (int i = 12; i < 22; i++)
{
replyDg[i] = decodeDg[i];
}
for (int i = 22; i < replyDg.Length; i++)
{
replyDg[i] = decodeDg[i + 1];
}
return replyDg;
}

What do you think?

73,
Barry W7BIK

[M0LTE]

Personally I would rather not leak the abstraction on that method- but I might consider exposing the UdpClient as a read-only property on the type, so that the calling code can break the abstraction if it chooses to. I’ll take a look what makes sense when I’m next in front of the IDE… Thanks so much for your input, it’s great to see use.

…

On Thu, 14 Mar 2024 at 16:46, Barry Kelman ***@***.***> wrote: Hi Tom, Yes, excellent point that the library should include the code to generate the Reply datagram, but I would think it belongs in a separate method in the ReplyMessage object, rather than including it in the Send() method in the WsjtxClient object. That way the Send() method stays flexible, so some future developer can use it for other message types when adding new functionality. Here's what I've got working today: public static byte[] GenerateReply(DecodeMessage decodeMessage) { byte[] decodeDg = decodeMessage.Datagram; byte[] replyDg = new byte[decodeDg.Length - 1]; for (int i = 0; i < 11; i++) { replyDg[i] = decodeDg[i]; } replyDg[11] = 4; for (int i = 12; i < 22; i++) { replyDg[i] = decodeDg[i]; } for (int i = 22; i < replyDg.Length; i++) { replyDg[i] = decodeDg[i + 1]; } return replyDg; } What do you think? 73, Barry W7BIK — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJAQNWHXTAEZ5FC5XVZ7UI3YYHH5TAVCNFSM6AAAAABETIMEYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXHA4DOOBXGE> . You are receiving this because you commented.Message ID: ***@***.***>

[barrykelman]

The other option would be to remove the 'sealed' attribute on the WsjtxClient class and make the udpClient field protected, so callers can just derive their own class.

Your call.

73, Barry W7BIK

[M0LTE]

Yep, that’s an option. I’ll come back to you later…

…

On Thu, 14 Mar 2024 at 17:00, Barry Kelman ***@***.***> wrote: The other option would be to remove the 'sealed' attribute on the WsjtxClient class and make the udpClient field protected, so callers can just derive their own class. Your call. 73, Barry W7BIK — Reply to this email directly, view it on GitHub <#2 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AJAQNWFZFGD5B4PNCXNUOFLYYHJRVAVCNFSM6AAAAABETIMEYWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMYTSOJXHEZDGOBZGQ> . You are receiving this because you commented.Message ID: ***@***.***>