View Issue Details

IDProjectCategoryView StatusLast Update
0002283Ham Radio DeluxeBugpublic2018-05-13 15:26
ReporterKB3NPH 
Assigned ToK7ZCZ 
PrioritynormalSeverityminorReproducibilityalways
Status closedResolutionfixed 
Product Version 
Target VersionFixed in Version6.4.0.840 
Summary0002283: Ticket #289104 - DM-780 Not reporting contacts already logged
DescriptionCustomer reports that when a callsign is entered in the DM-780 ALE, it indicates the contact "has not been worked" even though the contact IS in the operator's logbook.
Steps To ReproduceRun HRD, Logbook and DM-780.
In DM-780 place a callsign in the ALE that is known to exist in the Logbook and hit the "TAB" key.
Look at the bottom of the ALE and it will display "Not Worked" as though the contact has never been entered in the Logbook.

Additional InformationTicket #422168 - Another customer is experiencing the same issue described in this report.
TagsNo tags attached.
ModuleDM780
Sub-ModuleCall lookup
Testing Beta Successful

Relationships

Activities

KB3NPH

2018-02-10 07:45

administrator   ~0004311

Ticket #303249 Customer is indicating the "CHECK" for "Worked Status" is not being displayed in the Receive Pane of DM-780. I believe this is related to this same bug/topic.

K7ZCZ

2018-03-29 20:21

manager   ~0004597

Another user has provided this information through email:

v794 (maybe also v.787 and 792 ?)
Pick a call that is not in your log and add a QSO with that call using the DM ALE.
Once in the log, go back to the DM ALE and enter that call again
My results are as below: lookup 'not found' and 'not worked'
Lookup the same call in the logbook ALE and it will be fine

This is true for any call previously in the log, entered using v794, no matter if it was added in DM or LB ... But Only when you do a lookup in DM ALE

If you go back and load v780 this issue will not happen ... However, even in v.780, you can now no longer lookup a call/QSO that was previously added by DM v794 ... It seems DM v794 wrote something in each QSO record that causes this ... That's why I use the word "corrupted"

New QSO's added in v780 or earlier, will be just fine in either v780 of v794 ... You can go back in your log to an old QSO, added by some earlier version of HRD, and it will lookup as expected in either v780 or v794 ...

K7ZCZ

2018-03-29 20:22

manager   ~0004598

I spent some time yesterday setting up, and most of the day today testing and owrking on this issue.

I am unable to find any evidence of data corruption. I have two VMs, one with 780 and one with 797. I moved a database between them, so that I don't have to spend time uninstalling and reinstalling. After working around another issue, I readily able to add a recording using the DM780 ALE and see that record in the 797 Logbook. When adding looking for the same record from the DM780 ALE in 797 on the same database, I was able to see the record. The same experiment with the version roles swapped also worked as expected.

After adding a few records from each version into the same database, I examined the database directly. I saw no evidence of corruption and found that all of the records were (identical except for the expected differences in time stamps and such.)

The issue that initially prevented me from the scenario working is documented in Mantis 2638. It's conceivable that users are hitting that issue, though I don't think it's too likely. I'd like to hear feedback from those users about the state of their database configurations. Their answers will inform further action.

The code that implements communication between the different HRD apps is several layers, many different data structures and representations, and is pretty poorly factored. (That it exists at all is testament to poor architectural choice, really. But it's what we have.)

I've refactored some of the code directly involved in this lookup mechanism. It's a start, and the code is at least clearer and some comments have been added. There are several places where something might go wrong and prevent the ALE lookup in DM 780 from working correcly; there is poor error handling and therefore the user will be unlikely to notice and disabled from diagnosing any problems in this area.

To help colelct further information about what might be wrong here, I've added a few messages that trae activity with the feature. These messages will appear in the "Network" log in Logbook, and the "Logfile" in DM780.

The logfile feature in DM780 is accessed by using the "Logfile" command in the "View" menu. The command opens a dockable pane with diagnostic output from all parts of the application.

With the DM780 logfile open, a user will see messages that explain what callsign was searched and what the result was; the result information will say if the callsign was found or not; and if found, how many bands that callsign was seen on. The output looks like this:

17:19:54 Lookup: callsign "W8GGG" found, worked on 1 bands, not contest.
17:20:12 Lookup: callsign "W1RRR" not found

The Logbook's network log is accessible using the "Network Server" command in the "View" menu. It opens a dockable pane that contains logging information from the "Network Server" feature in the application, which is used to implement the cross-app communication (among other things).

With the Network Log open, when the logbook is queried by DM780 for a callsign, it will output information about the database being used, the success of the search, and the bands found. A sample output is given here:

17:59:24 Database: SQL Server Small
18:03:49 Lookup for callsign "K7ZCZ" returned 5 fields
18:03:49 Callsign "K7ZCZ" found on bands ""
18:03:49 Command: CallsignLookup, callsign=K7ZCZ

Support should gather feedback from users reporting the symptoms described in this issue by asking them to look at these logs while exercising the errant behaviour. Users should be encouraged to check on the messages in the network log and the logfile to see if they notice anything descriptive of the problem.

By colelcting some more information, I think we can find a way to diagnose the problem with certainty.

K7ZCZ

2018-03-29 20:24

manager   ~0004599

Note that I haven't positively ruled out a simpler bug; I'm unable to cause the problem as reported in this bug. The report doesn't include important information about the context in which the bug was observed -- most notably, the default Network Service database selected in the configuration of the Logbook. Maybe there are other settings or conditions which influence the behavior of this feature, but I have yet been unable to guess what they might be, beyond the setting for the default Network Server database.

By collecting log information, I hope that we can accurately collect that needed context and gain further clues that help solve the issue.

K7ZCZ

2018-03-30 18:20

manager   ~0004603

This shelf set is out for review with the above logging changes. Hopefully, seeing some details about what's failing might get us closer to a diagnosis ...

https://hrdsoftware.visualstudio.com/HRD/_versionControl/shelveset?ss=Refactoring%2C%20logging%20for%202283%3Bmikeblas%40msn.com

K7ZCZ

2018-04-01 12:13

manager   ~0004613

This checkin is made; the issue should remain open as we collect more information about what's happening and approach a diagnosis.

https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4007

KB3NPH

2018-04-02 10:31

administrator   ~0004624

The following additional information was posted in OSTicket #886495

Ronald posted 03/30/2018 2:22 PM
Tim,

It seems the only thing that fixes the problem is zero auto uploads ... I went to 2 auto uploads to 1 auto upload and both failed ... The actual upload takes place but it screws up the DM-780 ALE look ups ... I only tried EQSL and QRZ as 1 and 2 ....
 Reopened by w3rjw@verizon.net 03/30/2018 2:22 PM
Avatar

Ronald posted 03/31/2018 8:16 AM
Problem is complex .... Above I said everything was working as long as I didn't auto upload QSOs ... I then loaded QSO's to each sight manually ... then everything was fubar for those calls as previously described ...

If you don't upload QSO's to an external sight, then even with a restart every thing will be OK ..

Steps to reproduce:

1) Add a QSO via the DM-780 ALE.

2) Check to see Data looked up OK .... It will be OK

3) Manually or automatically upload QSO to say EQSL

4) Check to see Data lookup still OK ... It won't be ... 'not found' and not worked before

All through this Logbook ALE look-ups are fine

This all started on a specific date as above ...
Avatar

Ronald posted 03/31/2018 8:23 AM
Just to add: Once these calls are removed from the log, look-up will again be OK ...
Avatar

Ronald posted 04/02/2018 8:22 AM
I've narrowed it down further: You can auto or manual upload to Clublog and/or HRDlog.net ( these upload in background, related or not ?) and everything behaves as expected ..... However, if you upload to EQSL or QRZ, (these refresh log after upload) manually or auto, then you get the 'not found', 'not worked before' the next time you enter that call ...

Everything I have said thus far is true, but only for specific external logbooks ....

KB3NPH

2018-04-04 09:12

administrator   ~0004668

Mike, the following information has been provided by Ron Whitesel as follow-up information.

Ronald posted 03/31/2018 8:23 AM
Just to add: Once these calls are removed from the log, look-up will again be OK ...
Avatar
Ronald posted 04/02/2018 8:22 AM
I've narrowed it down further: You can auto or manual upload to Clublog and/or HRDlog.net ( these upload in background, related or not ?) and everything behaves as expected ..... However, if you upload to EQSL or QRZ, (these refresh log after upload) manually or auto, then you get the 'not found', 'not worked before' the next time you enter that call ...

Everything I have said thus far is true, but only for specific external logbooks ....

Please pass on to Mike B.
Avatar
Tim (KB3NPH) posted 04/02/2018 11:18 AM
Why aren't you in our beta testing program???

Avatar
Ronald posted 04/02/2018 12:52 PM
First ... I think it's the EQSL uploads that FUBARS subsequent lookups ....

I got to thinking what was different about EQSL and the only thing I thought of it has EQSL sent /received logbook columns and thus code ....

Tim,

To answer your question, Mike C has been after me for years ... I feel I have more value as an independent contractor so to speak ... I am also a very active ham that uses HRD every day making contacts and I don't want to chance mucking up my machine

I wish there was someway I could just report things into the system as I find them without committing to downloading and installing Beta versions ..... I have a full up, fully interfaced to other systems and gadgets, machine ... I upload to all the logbooks, I use DM-780 for FSK, soundcard modes and CW, I use JTalert and WSJTX ... I think I see situations that a "tester" of specific fixes might not see ...

Anyway that's the way I feel ...
Avatar
Ronald posted 04/03/2018 7:13 AM
FYI: Note on EQSL WEB page .....

"* Our database is now ADIF 3.0.8 compliant. Make sure you upgrade your logging software, especially if you operate JT4, JT9, JT65, OLIVIA, OPERA, PSK, or others that may have SUBMODEs that have changed recently in the ADIF spec."

KB3NPH

2018-04-13 09:32

administrator   ~0004815

Ronald posted 04/12/2018 4:41 PM
Ok Tim... I know just enough to be dangerous ...
Please post just the following in Mantis: It's an excerpt from an e-mail conversation I had with Mike C. Mike C. has probably already forwarded to Mike B, but I want to make sure Mike B. sees it in context ...
1) Mantis 2283 Callsign lookup --- I had narrowed the problem to e-QSL uploads causing the issue ... Another user posted on the forums his possible solution .. I tried it - It works (I edited a record to test)
Look here please:
https://forums.ham-radio-deluxe.com/node/45654?p=46178
Note HTML comments added to record ...

Ron W3RJW

K7ZCZ

2018-04-15 16:09

manager   ~0004834

I report that I have a hard time following the narrative here; looks like I'm not seeing the entire conversation, as there are repeated paragraps and referenes to things like "thus far" and "above I said", but the referred conversations are not clearly identified.

It looks like the claim is that upoading to eQSL.cc can alter a logbook record with the status form eQSL.cc, which might include some commented HTML entities, like this:

   <!-- Access Log -->, <!-- In access log -->


and that, when those entities are present, the log entry can't be found using the DM780 "Add Log Entry" pane; but removing the comment entities makes it so the

This seems to be confirmed by a post made by user Vozhd, here: https://forums.ham-radio-deluxe.com/node/45654?p=46130#post46130

I believe I am so far able to repro this issue, given Vozhd's clear description. Here's what I'm doing:

1) I've imported into Logbook a small ADIF file with some contacts I've recently made.
2) I've uploaded all of them to eQSL.cc. I've edited a few to not include the "access log" comments
3) Starting DM780, I observe that I get "not worked" for any callsign I test that does have "Access Log" comments
4) get "worked" as expected for any callsign which I've edited to not include "Access Log" comments.

Armed with this, I'll see if I can figure out what's happening.

K7ZCZ

2018-04-15 20:17

manager   ~0004835

OnQRZLookup receives a QRZ_COM_DATA with bFound = FALSE

nMsgQRZLookup is sent to call OnQRZLookup


nMsgQRZLookup is sent to descendants from CStandardLogbookMain::OnQRZLookup() with results

For KA9VRX we receive this; note that Value16 is not escaped and the HTML entities are raw

<?xml version="1.0"?>
<HRD xml:lang="EN"><body><Country>United States</Country><DXCC>291</DXCC><IOTA></IOTA><cqzone>5</cqzone><ituzone>6</ituzone><Address1>1625 Holler Rd</Address1><Address2>Mount Vernon</Address2><AreaCode>812</AreaCode><Callsign>KA9VRX</Callsign><Class>E</Class><Codes>HAI</Codes><DST>Y</DST><Effective>2010-06-29</Effective><Email>ka9vrx@yahoo.com</Email><Eqsl>1</Eqsl><Expires>2020-09-25</Expires><Fips>18129</Fips><Fname>Melvin D</Fname><GMTOffset>-6</GMTOffset><Gridsquare>EM67av</Gridsquare><Land>United States</Land><LastUpdate>2016-02-27 18:12:30</LastUpdate><Latitude>37.906999</Latitude><Locref>1</Locref><Longitude>-87.956814</Longitude><Mqsl>1</Mqsl><MSA>2440</MSA><Name>Ziegler</Name><QSLInfo>DIRECT, EQSL AND LOTW</QSLInfo><State>IN</State><TimeZone>Central</TimeZone><UsCounty>Posey</UsCounty><Zip>47620</Zip><Biography>http://xmldata.qrz.com/xml?s=9f40b7ee82491b34c255ebecf4cbd977&html=KA9VRX</Biography><Bands>30m</Bands></body><settings FirstName="0"/><adif fields_count="61" fields_value_0="PRIMARY_KEY" fields_value_1="AGE" fields_value_2="A_INDEX" fields_value_3="ANT_AZ" fields_value_4="ANT_EL" fields_value_5="BAND" fields_value_6="CALL" fields_value_7="COMMENT" fields_value_8="CONT" fields_value_9="COUNTRY" fields_value_10="CQZ" fields_value_11="DISTANCE" fields_value_12="DXCC" fields_value_13="EQSL_QSLSDATE" fields_value_14="EQSL_QSL_RCVD" fields_value_15="EQSL_QSL_SENT" fields_value_16="EQSL_STATUS" fields_value_17="FORCE_INIT" fields_value_18="FREQ" fields_value_19="FREQ_RX" fields_value_20="GRIDSQUARE" fields_value_21="HEADING" fields_value_22="ITUZ" fields_value_23="K_INDEX" fields_value_24="LOTW_QSL_RCVD" fields_value_25="LOTW_QSL_SENT" fields_value_26="MAX_BURSTS" fields_value_27="MODE" fields_value_28="MY_CITY" fields_value_29="MY_CNTY" fields_value_30="MY_CQ_ZONE" fields_value_31="MY_GRIDSQUARE" fields_value_32="MY_ITU_ZONE" fields_value_33="MY_LAT" fields_value_34="MY_LON" fields_value_35="MY_NAME" fields_value_36="MY_RIG" fields_value_37="NR_BURSTS" fields_value_38="NR_PINGS" fields_value_39="OPERATOR" fields_value_40="PFX" fields_value_41="QSL_RCVD" fields_value_42="QSL_SENT" fields_value_43="QSO_COMPLETE" fields_value_44="QSO_RANDOM" fields_value_45="RST_RCVD" fields_value_46="RST_SENT" fields_value_47="RX_PWR" fields_value_48="SFI" fields_value_49="SRX" fields_value_50="STATION_CALLSIGN" fields_value_51="STX" fields_value_52="SWL" fields_value_53="TEN_TEN" fields_value_54="TIME_OFF" fields_value_55="TIME_ON" fields_value_56="TX_PWR" fields_value_57="USER_DEFINED_9" fields_value_58="CREDIT_GRANTED" fields_value_59="CREDIT_SUBMITTED" fields_value_60="HRDCOUNTRYNO" values_count="61" values_value_0="26" values_value_1="0" values_value_2="0.0" values_value_3="0.0" values_value_4="0.0" values_value_5="30m" values_value_6="KA9VRX" values_value_7="Thanks for the contact! 73" values_value_8="NA" values_value_9="United States" values_value_10="0" values_value_11="1905" values_value_12="291" values_value_13="2018-04-15" values_value_14="No" values_value_15="Yes" values_value_16="Warning: Y=2018 M=04 D=14 KA9VRX 30M FT8 Bad record: Duplicate, Result: 0 out of 1 records added, <!-- Access Log -->, <!-- In access log -->" values_value_17="0" values_value_18="10.136.760" values_value_19="0" values_value_20="EM67" values_value_21="98" values_value_22="0" values_value_23="0.0" values_value_24="No" values_value_25="No" values_value_26="0" values_value_27="FT8" values_value_28="Mercer Island" values_value_29="canada" values_value_30="0" values_value_31="CN87vn" values_value_32="0" values_value_33="47.5625000000" values_value_34="-122.2083330000" values_value_35="Mike Blaszczak" values_value_36="Yaesu FT-450D" values_value_37="0" values_value_38="0" values_value_39="K7ZCZ" values_value_40="KA9" values_value_41="No" values_value_42="No" values_value_43="Y" values_value_44="0" values_value_45="-12" values_value_46="-06" values_value_47="0.0" values_value_48="0.0" values_value_49="0" values_value_50="K7ZCZ" values_value_51="0" values_value_52="0" values_value_53="0" values_value_54="23:36:15" values_value_55="2018-04-14@23:34:45" values_value_56="80.000" values_value_57="04/14/2018 233445" values_value_58="                                                                                              " values_value_59="                                                                                              " values_value_60="291"/></HRD>


CStandardLogbookMain::OnQRZLookup() receives nMsgQRZLookup from the callback API

CLogbookInterface::CallsignLookup accepts parameters and does the lookup. Calls SendCommand() with an HRDLOG_DATA structure, including the reply message (which is, inconveniently, nMsgQRZLookup).

Command is OPT_CALLSIGNLOOKUP, translated to "Callsign lookup" in CLogbookInterface::SendCommand()

Command with HRDLOG_DATA is given to CBackgroundProcessingThread::RequestLogbookCommand().

Actually processed in CBackgroundProcessingThread::LogbookCommand() ; large switch statement there finds OPT_CALLSIGNLOOKUP, then calls PostMessage pData->nReplyMsg to send the pData back

OPT_CALLSIGNLOOKUP calls HRDLogbookInterfaceCallsignLookup()

HRDLogbookInterfaceCallsignLookup() builds an XML string with the request, then calls App().SendRecvXML()

App().SendRecvXML() has the XML like this:

<?xml version="1.0"?>
<!--                                                                    -->
<!-- ===================== WARNING ==========================           -->
<!-- | The contents of this file must not be changed if the |           -->
<!-- | program is to operate correctly. To avoid problems,  |           -->
<!-- | please do NOT edit this file.                        |           -->
<!-- ========================================================           -->
<!--                                                                    -->
<!-- Filename ..: HRDLogbookInterface                                   -->
<!-- Created ...: 2018-04-15 15:01:38                                   -->
<!-- Computer ..: SLED                                                  -->
<!-- Username ..: mikeblas                                              -->
<!-- Program ...: Digital Master.exe                                    -->
<!--                                                                    -->
<!-- c:\ham radio\logbook\hrdlogbookinterface\hrdlogbookxml.cpp line 52 -->
<!--                                                                    -->
<HRDLogbookInterface xml:lang="EN" Description="Layouts" Created="15-Apr-2018 15:01"><Command Callsign="W0ALA">CallsignLookup</Command><Return Lookup="<?xml version="1.0"?>&#xA;<HRD xml:lang="EN"><body><Country>United States</Country><DXCC>291</DXCC><IOTA></IOTA><cqzone>5</cqzone><ituzone>6</ituzone><Address1>502 Savannah Lane</Address1><Address2>Westfield</Address2><AreaCode>317</AreaCode><Born>1955</Born><Callsign>W0ALA</Callsign><Class>G</Class><Codes>HVIE</Codes><DST>Y</DST><Effective>2015-05-12</Effective><Email>w0ala@arrl.net</Email><Expires>2025-05-12</Expires><Fips>18057</Fips><Fname>Anthony L</Fname><GMTOffset>-5</GMTOffset><Gridsquare>EN60wb</Gridsquare><Land>United States</Land><LastUpdate>2015-10-14 16:01:51</LastUpdate><Latitude>40.047699</Latitude><Locref>3</Locref><Longitude>-86.120163</Longitude><MSA>3480</MSA><Name>Ashpaugh</Name><Previous>KD9DPL</Previous><State>IN</State><TimeZone>Eastern</TimeZone><UsCounty>Hamilton</UsCounty><Zip>46074</Zip><Bands>30m</Bands></body><settings FirstName="0"/><adif fields_count="61" fields_value_0="PRIMARY_KEY" fields_value_1="AGE" fields_value_2="A_INDEX" fields_value_3="ANT_AZ" fields_value_4="ANT_EL" fields_value_5="BAND" fields_value_6="CALL" fields_value_7="COMMENT" fields_value_8="CONT" fields_value_9="COUNTRY" fields_value_10="CQZ" fields_value_11="DISTANCE" fields_value_12="DXCC" fields_value_13="EQSL_QSLSDATE" fields_value_14="EQSL_QSL_RCVD" fields_value_15="EQSL_QSL_SENT" fields_value_16="EQSL_STATUS" fields_value_17="FORCE_INIT" fields_value_18="FREQ" fields_value_19="FREQ_RX" fields_value_20="GRIDSQUARE" fields_value_21="HEADING" fields_value_22="ITUZ" fields_value_23="K_INDEX" fields_value_24="LOTW_QSL_RCVD" fields_value_25="LOTW_QSL_SENT" fields_value_26="MAX_BURSTS" fields_value_27="MODE" fields_value_28="MY_CITY" fields_value_29="MY_CNTY" fields_value_30="MY_CQ_ZONE" fields_value_31="MY_GRIDSQUARE" fields_value_32="MY_ITU_ZONE" fields_value_33="MY_LAT" fields_value_34="MY_LON" fields_value_35="MY_NAME" fields_value_36="MY_RIG" fields_value_37="NR_BURSTS" fields_value_38="NR_PINGS" fields_value_39="OPERATOR" fields_value_40="PFX" fields_value_41="QSL_RCVD" fields_value_42="QSL_SENT" fields_value_43="QSO_COMPLETE" fields_value_44="QSO_RANDOM" fields_value_45="RST_RCVD" fields_value_46="RST_SENT" fields_value_47="RX_PWR" fields_value_48="SFI" fields_value_49="SRX" fields_value_50="STATION_CALLSIGN" fields_value_51="STX" fields_value_52="SWL" fields_value_53="TEN_TEN" fields_value_54="TIME_OFF" fields_value_55="TIME_ON" fields_value_56="TX_PWR" fields_value_57="USER_DEFINED_9" fields_value_58="CREDIT_GRANTED" fields_value_59="CREDIT_SUBMITTED" fields_value_60="HRDCOUNTRYNO" values_count="61" values_value_0="23" values_value_1="0" values_value_2="0.0" values_value_3="0.0" values_value_4="0.0" values_value_5="30m" values_value_6="W0ALA" values_value_7="Thanks for the contact! 73" values_value_8="NA" values_value_9="United States" values_value_10="0" values_value_11="1800" values_value_12="291" values_value_13="2018-04-15" values_value_14="No" values_value_15="Yes" values_value_16="Warning: Y=2018 M=04 D=14 W0ALA 30M FT8 Bad record: Duplicate, Result: 0 out of 1 records added, &lt;!-- Access Log --&gt;, &lt;!-- In access log --&gt;" values_value_17="0" values_value_18="10.136.979" values_value_19="0" values_value_20="EN60" values_value_21="92" values_value_22="0" values_value_23="0.0" values_value_24="No" values_value_25="No" values_value_26="0" values_value_27="FT8" values_value_28="Mercer Island" values_value_29="canada" values_value_30="0" values_value_31="CN87vn" values_value_32="0" values_value_33="47.5625000000" values_value_34="-122.2083330000" values_value_35="Mike Blaszczak" values_value_36="Yaesu FT-450D" values_value_37="0" values_value_38="0" values_value_39="K7ZCZ" values_value_40="W0" values_value_41="No" values_value_42="No" values_value_43="Y" values_value_44="0" values_value_45="-16" values_value_46="-16" values_value_47="0.0" values_value_48="0.0" values_value_49="0" values_value_50="K7ZCZ" values_value_51="0" values_value_52="0" values_value_53="0" values_value_54="23:25:30" values_value_55="2018-04-14@23:23:30" values_value_56="80.000" values_value_57="04/14/2018 232330" values_value_58="                                                                                              " values_value_59="                                                                                              " values_value_60="291"/></HRD>&#xA;"/></HRDLogbookInterface>


... with some escaping, trying to send inside an envelope?


HRDLogbookInterfaceCallsignLookup calls App().GetXMLValue() to get "Lookup" field out of this XML; it is unpacked from the <Return Lookup="this data"> tag.

At this point, the returned XML is as the first block, with HTML comments raw in the tag value. And it is NOT like the second block, with the escaping.

The message is sent, we end up in CStandardLogbookMain::OnQRZLookup() an try to get the XML string into an XML manager. It fails to load with:

Error Description = Validate failed because the document does not contain exactly one root node.
: 0: 0

The root XML node can't be attained from the document, no parsing is done. Everything is empty.

CIpThread::DispatchCommand() creates the <Return> XML node.

DispatchCommand() creates a CIPListenerCallsignLookup object and initializes it with pReturn node, calls Perform on that object to do the lookup.

So! The flaw is that the implementation of CIPListenerCallsignLookup ends up appending the XML it generates as a value to a property in an XML node. There, it isn't safe to have characters which might need to be escaped. Fortunately, the mechanism used here is unique to CIPListenerCallsignLookup; while this is a symptom of a terrible design held up by an absolutely awful implementation, we've avoided serious trouble with luck.

K7ZCZ

2018-04-15 20:26

manager   ~0004836

Last edited: 2018-04-15 21:43

View 2 revisions

The fix I've implemented is, for CIPListenerCallsignLookup, to append the result of teh call as a CDATA node underneath the identified <Return> node. That way, we've a lot less to worry about for escaping the XML document that was benig added as a value to a property in a node of another XML document.

For a record that does have the HTML comments in it, the CDATA version of the XML looks like this, now.

<?xml version="1.0"?>
<!--                                                                    -->
<!-- ===================== WARNING ==========================           -->
<!-- | The contents of this file must not be changed if the |           -->
<!-- | program is to operate correctly. To avoid problems,  |           -->
<!-- | please do NOT edit this file.                        |           -->
<!-- ========================================================           -->
<!--                                                                    -->
<!-- Filename ..: HRDLogbookInterface                                   -->
<!-- Created ...: 2018-04-15 18:23:55                                   -->
<!-- Computer ..: SLED                                                  -->
<!-- Username ..: mikeblas                                              -->
<!-- Program ...: Digital Master.exe                                    -->
<!--                                                                    -->
<!-- c:\ham radio\logbook\hrdlogbookinterface\hrdlogbookxml.cpp line 52 -->
<!--                                                                    -->
<HRDLogbookInterface xml:lang="EN" Description="Layouts" Created="15-Apr-2018 18:23"><Command Callsign="W0ALA">CallsignLookup</Command><Return><![CDATA[<?xml version="1.0"?>
<HRD xml:lang="EN"><body><Country>United States</Country><DXCC>291</DXCC><IOTA></IOTA><cqzone>5</cqzone><ituzone>6</ituzone><Address1>502 Savannah Lane</Address1><Address2>Westfield</Address2><AreaCode>317</AreaCode><Born>1955</Born><Callsign>W0ALA</Callsign><Class>G</Class><Codes>HVIE</Codes><DST>Y</DST><Effective>2015-05-12</Effective><Email>w0ala@arrl.net</Email><Expires>2025-05-12</Expires><Fips>18057</Fips><Fname>Anthony L</Fname><GMTOffset>-5</GMTOffset><Gridsquare>EN60wb</Gridsquare><Land>United States</Land><LastUpdate>2015-10-14 16:01:51</LastUpdate><Latitude>40.047699</Latitude><Locref>3</Locref><Longitude>-86.120163</Longitude><MSA>3480</MSA><Name>Ashpaugh</Name><Previous>KD9DPL</Previous><State>IN</State><TimeZone>Eastern</TimeZone><UsCounty>Hamilton</UsCounty><Zip>46074</Zip><Bands>30m</Bands></body><settings FirstName="0"/><adif fields_count="61" fields_value_0="PRIMARY_KEY" fields_value_1="AGE" fields_value_2="A_INDEX" fields_value_3="ANT_AZ" fields_value_4="ANT_EL" fields_value_5="BAND" fields_value_6="CALL" fields_value_7="COMMENT" fields_value_8="CONT" fields_value_9="COUNTRY" fields_value_10="CQZ" fields_value_11="DISTANCE" fields_value_12="DXCC" fields_value_13="EQSL_QSLSDATE" fields_value_14="EQSL_QSL_RCVD" fields_value_15="EQSL_QSL_SENT" fields_value_16="EQSL_STATUS" fields_value_17="FORCE_INIT" fields_value_18="FREQ" fields_value_19="FREQ_RX" fields_value_20="GRIDSQUARE" fields_value_21="HEADING" fields_value_22="ITUZ" fields_value_23="K_INDEX" fields_value_24="LOTW_QSL_RCVD" fields_value_25="LOTW_QSL_SENT" fields_value_26="MAX_BURSTS" fields_value_27="MODE" fields_value_28="MY_CITY" fields_value_29="MY_CNTY" fields_value_30="MY_CQ_ZONE" fields_value_31="MY_GRIDSQUARE" fields_value_32="MY_ITU_ZONE" fields_value_33="MY_LAT" fields_value_34="MY_LON" fields_value_35="MY_NAME" fields_value_36="MY_RIG" fields_value_37="NR_BURSTS" fields_value_38="NR_PINGS" fields_value_39="OPERATOR" fields_value_40="PFX" fields_value_41="QSL_RCVD" fields_value_42="QSL_SENT" fields_value_43="QSO_COMPLETE" fields_value_44="QSO_RANDOM" fields_value_45="RST_RCVD" fields_value_46="RST_SENT" fields_value_47="RX_PWR" fields_value_48="SFI" fields_value_49="SRX" fields_value_50="STATION_CALLSIGN" fields_value_51="STX" fields_value_52="SWL" fields_value_53="TEN_TEN" fields_value_54="TIME_OFF" fields_value_55="TIME_ON" fields_value_56="TX_PWR" fields_value_57="USER_DEFINED_9" fields_value_58="CREDIT_GRANTED" fields_value_59="CREDIT_SUBMITTED" fields_value_60="HRDCOUNTRYNO" values_count="61" values_value_0="23" values_value_1="0" values_value_2="0.0" values_value_3="0.0" values_value_4="0.0" values_value_5="30m" values_value_6="W0ALA" values_value_7="Thanks for the contact! 73" values_value_8="NA" values_value_9="United States" values_value_10="0" values_value_11="1800" values_value_12="291" values_value_13="2018-04-15" values_value_14="No" values_value_15="Yes" values_value_16="Warning: Y=2018 M=04 D=14 W0ALA 30M FT8 Bad record: Duplicate, Result: 0 out of 1 records added, <!-- Access Log -->, <!-- In access log -->" values_value_17="0" values_value_18="10.136.979" values_value_19="0" values_value_20="EN60" values_value_21="92" values_value_22="0" values_value_23="0.0" values_value_24="No" values_value_25="No" values_value_26="0" values_value_27="FT8" values_value_28="Mercer Island" values_value_29="canada" values_value_30="0" values_value_31="CN87vn" values_value_32="0" values_value_33="47.5625000000" values_value_34="-122.2083330000" values_value_35="Mike Blaszczak" values_value_36="Yaesu FT-450D" values_value_37="0" values_value_38="0" values_value_39="K7ZCZ" values_value_40="W0" values_value_41="No" values_value_42="No" values_value_43="Y" values_value_44="0" values_value_45="-16" values_value_46="-16" values_value_47="0.0" values_value_48="0.0" values_value_49="0" values_value_50="K7ZCZ" values_value_51="0" values_value_52="0" values_value_53="0" values_value_54="23:25:30" values_value_55="2018-04-14@23:23:30" values_value_56="80.000" values_value_57="04/14/2018 232330" values_value_58="                                                                                              " values_value_59="                                                                                              " values_value_60="291"/></HRD>
]]></Return></HRDLogbookInterface>


K7ZCZ

2018-04-16 09:14

manager   ~0004838

fixed with this checkin:
https://hrdsoftware.visualstudio.com/HRD/_versionControl/changeset/4058

PD9FER

2018-04-20 11:44

viewer   ~0004863

Just got out of a remote with a OM..
Got a PSR file, it is on Google drive in dumps, called Problems.zip

Just a FYI, because it seems to be fixed in the next release

g3ucq

2018-05-04 11:06

viewer   ~0004943

Fixed for me

Issue History

Date Modified Username Field Change
2017-11-21 09:55 KB3NPH New Issue
2018-02-10 07:45 KB3NPH Note Added: 0004311
2018-02-14 11:37 KB3NPH Additional Information Updated View Revisions
2018-03-27 00:44 K7ZCZ Assigned To => K7ZCZ
2018-03-27 00:44 K7ZCZ Status new => assigned
2018-03-29 20:21 K7ZCZ Note Added: 0004597
2018-03-29 20:22 K7ZCZ Note Added: 0004598
2018-03-29 20:24 K7ZCZ Note Added: 0004599
2018-03-30 18:20 K7ZCZ Note Added: 0004603
2018-04-01 12:13 K7ZCZ Note Added: 0004613
2018-04-02 10:31 KB3NPH Note Added: 0004624
2018-04-04 09:12 KB3NPH Note Added: 0004668
2018-04-13 09:32 KB3NPH Note Added: 0004815
2018-04-15 16:09 K7ZCZ Note Added: 0004834
2018-04-15 20:17 K7ZCZ Note Added: 0004835
2018-04-15 20:26 K7ZCZ Note Added: 0004836
2018-04-15 21:43 K7ZCZ Note Edited: 0004836 View Revisions
2018-04-16 09:14 K7ZCZ Status assigned => resolved
2018-04-16 09:14 K7ZCZ Resolution open => fixed
2018-04-16 09:14 K7ZCZ Note Added: 0004838
2018-04-17 07:25 K7ZCZ Project 1 - Backlog => 3 - Current Dev List
2018-04-20 11:44 PD9FER Note Added: 0004863
2018-05-03 20:10 K7ZCZ Fixed in Version => 6.4.0.837
2018-05-04 11:06 g3ucq Note Added: 0004943
2018-05-12 01:10 WA9PIE Status resolved => closed
2018-05-12 01:10 WA9PIE Testing Not Started => Beta Successful
2018-05-13 15:25 WA9PIE Fixed in Version 6.4.0.837 => 6.4.0.840
2018-05-13 15:26 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe