Building Applications that Interoperate with DXLab Applications


DXLab applications interoperate by sending each other messages, and by monitoring broadcasts. Commander, for example, will accept a message directing it to QSY the primary transceiver to a specified frequency; Commander also broadcasts the primary transceiver's current frequency, allowing applications like DXKeeper and WinWarbler to track frequency changes in real time. Any application can direct a DXLab application to perform operations by sending it appropriate messages; any application can also monitor a DXLab application's broadcasts. The primary mechanism used to implement both forms of interoperation -- message passing and broadcasting -- is Microsoft's Dynamic Data Exchange (DDE). In addition, some DXLab applications support interoperatiojn via the UDP and TCP/IP protocols.

Interoperation via DDE

Every DXLab application except the Launcher accepts messages; several DXLab applications also broadcast important items of state, e.g. the primary transceiver's current frequency, mode, selected VFO, S-meter, split, and model. The use of these messages and broadcasts is documented and illustrated in a pedagogical application called DXLabTest,  which is provided in both source code (Visual Basic version 6) and executable form. DXLabTest's user interface consists of seven tabs, each of which illustrates the interoperational capabilities of a particular DXLab application. These capabilities can be explored by running DXLabTest's executable; they can be understood by reviewing DXLabTest's source code, from which Developers are free to extract code for use in their own applications. Similarly, an application called Sample illustrates control of Commander using Microsoft's C# language.

This open approach has encouraged the development of more than twenty applications that interoperate with DXLab applications. Some of these applications extend or complement DXLab; others provide access to alternative implementations of functionality provided by DXLab. In all cases, the DXLab user community gains access to more capability without sacrificing interoperability.

The use of DDE to interoperate with DXLab applications has been accomplished in applications written in Microsoft's Visual Basic, Microsoft's .net languages, and Borland/Codegear's C++ and Delphi languages.


DXLabTest - zip archive containing both source code and an executable illustrating control of seven DXLab applications via DDE and TCP/IP messages using Microsoft Visual Basic version 6

CSharp.NET Sample -- zip archive containing source code and an executable illustrating control of Commander via DDE messages using Microsoft C#.NET (tnx to Rich W3ZJ)

VB.NET Sample -- zip archive containing source code and an executable illustrating control of Commander via DDE messages using Microsoft VB.NET (tnx to Rich W3ZJ)


Interoperation via UDP

Commander can be configured to issue the N1MM-defined RadioInfo UDP message, as described here.

Interoperation via TCP

Commander can be configured to respond to directives received in TCP messages, as described here. The format of these messages is documented here.

DXKeeper accepts a TCP message beginning with the externallog command directing it to log a QSO in a manner governed by multiple parameters:

For example, receipt of the message

<command:11>externallog<parameters:341><ExternalLogADIF:187><CALL:4>P5DX <RST_SENT:3>599 <RST_RCVD:3>599 <FREQ:6>14.004 <BAND:3>20M <MODE:2>CW <QSO_DATE:8>20220411 <TIME_ON:6>072800 <STATION_CALLSIGN:5>AA6YQ <TX_PWR:4>1000 <GRIDSQUARE:4>PM29 <EOR><UploadeQSL:1>Y<UploadLoTW:1>Y<UploadClubLog:1>Y<DeduceMissing:1>Y<QueryCallbook:1>Y<UpdateeQSL:1>Y<UpdateLoTW:1>Y<CheckOverrides:1>Y

would result in logging a QSO with P5DX on 140004 kHz in CW on 2022-04-11 at 0728Z in Grid PM29 with 1000 watts; the override list would be checked for the presence of P5DX, missing items would be deduced from available databases, the currently-selected callbook would be queried for additional information, the logged QSO's eQSL and LoTW membership items would be set to Y, and the logged QSO would be submitted to Club Log, eQSL, and LoTW.