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.
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)
Commander can be configured to issue the N1MM-defined RadioInfo UDP message, as described here.
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:
<Parameters:N> - N is the total length of the ExternalLogADIF field and all specified option fields
<ExternalLogADIF:M>valid ADIF record of length M - the QSO to be logged
Options - a subset of the General Options available for importing QSOs
<UploadeQSL:1>Y - if present, submit the logged QSO to eQSL
<UploadLoTW:1>Y - if present, submit the logged QSO to LoTW
<DeduceMissing:1>Y - if present, deduce items missing from the QSO to be logged from the entity, primary subdivision, and USAP databases
<QueryCallbook:1>Y - if present, query the currently selected Callbook, DXCC database, and RDA database for missing items
<UpdateeQSL:1>Y - if present, query the eQSL database to determine if the callsign specified in the ADIF record is an authenticity-guaranteed member of eQSL, and if so set the QSO's eQSL Member item to A
<UpdateLoTW:1>Y - if present, query the eQSL database to determine if the callsign specified in the ADIF record has submitted QSOs to LoTW to LoTW within the specified interval, and if so set the QSO's LotW Member item to Y
<CheckOverrides:1>Y - if present, query the Override list for the presence of the callsign specified in the QSO to be logged; if found, update the logged QSO with the information specified in the override
<UploadClubLog:1>Y - if present, submit the logged QSO to Club Log
<UploadQRZ:1>Y - if present, submit the logged QSO to QRZ
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.
Notes:
If the Auto upload box on the QSL Configuration window’s Club Log tab is checked, the logged QSO will be uploaded to Club Log whether and UploadClubLog parameter is present or not
If the Auto upload box on the QSL Configuration window’s QRZ tab is checked, the logged QSO will be uploaded to QRZ whether andUploadCQRZ parameter is present or not
DXKeeper can accepts a directive to filter its Log Page Display, and a directive to delete a logged QSO. For information about these directive, contact AA6YQ via aa6yq (at) ambersoft.com.