UDP Logging strips carriage returns from multiline Address

[VK3AMA]

Examining the Communicator Log file, I see the data sent, including the Carriage Returns and Line feeds in the multi-line address field. Double-checking, I examined the file in a hex editor and the Carriage Returns are present.

I performed two tests, first sending the data as a string and the second as binary data. Both produced the same result.

This tends to confirm that the Carriage Returns are not being lost in transmission.

2016-05-27 17:22:11.8354 INFO: TCPManagement: Incoming QSO from TCP Connection (ADD)
2016-05-27 17:22:11.8584 INFO: #=qOmwHU$0t9BdIB_$u51haOokYXiNjo59IUqVlyVgvuA0=: Incoming TCP QSO <CALL:6>VK3AMA<DXCC:3>150<COUNTRY:9>Australia<QSO_DATE:8>20160527<QSO_DATE_OFF:8>20160527<TIME_ON:6>072100<TIME_OFF:6>072200<FREQ:9>144.49029<FREQ_RX:9>144.49029<BAND:2>2m<BAND_RX:2>2m<MODE:3>JT9<GRIDSQUARE:4>IO82<DISTANCE:5>17074<LAT:11>N052 30.000<LON:11>W003 00.000<COMMENT:3>JT9<QSLMSG:3>JT9<NAME:14>Laurie Cowcher<QTH:14>Chirnside Park<ADDRESS:28>Sent As String
Line2
Line3<CQZ:2>30<ITUZ:2>59<PFX:3>VK3<CONT:2>OC<MY_GRIDSQUARE:6>QF22pf<MY_CQ_ZONE:2>30<MY_ITU_ZONE:2>59<STATION_CALLSIGN:5>VK3TC<QSO_COMPLETE:1>Y <EOR>

2016-05-27 17:23:10.5247 INFO: TCPManagement: Incoming QSO from TCP Connection (ADD)
2016-05-27 17:23:10.5297 INFO: #=qOmwHU$0t9BdIB_$u51haOokYXiNjo59IUqVlyVgvuA0=: Incoming TCP QSO <CALL:6>VK3AMA<DXCC:3>150<COUNTRY:9>Australia<QSO_DATE:8>20160527<QSO_DATE_OFF:8>20160527<TIME_ON:6>072300<TIME_OFF:6>072300<FREQ:9>144.49029<FREQ_RX:9>144.49029<BAND:2>2m<BAND_RX:2>2m<MODE:3>JT9<GRIDSQUARE:4>IO82<DISTANCE:5>17074<LAT:11>N052 30.000<LON:11>W003 00.000<COMMENT:3>JT9<QSLMSG:3>JT9<NAME:14>Laurie Cowcher<QTH:14>Chirnside Park<ADDRESS:28>Sent As Binary
Line2
Line3<CQZ:2>30<ITUZ:2>59<PFX:3>VK3<CONT:2>OC<MY_GRIDSQUARE:6>QF22pf<MY_CQ_ZONE:2>30<MY_ITU_ZONE:2>59<STATION_CALLSIGN:5>VK3TC<QSO_COMPLETE:1>Y <EOR>

de Laurie, VK3AMA

[IW3HMH]

Yes, i'm following the White rabbit through the code to find where is stripped away

[IW3HMH]

I made a custom test that uses the TcpEventManager.AddQSO function, that is the function on Log4OMUI.exe side that receives the packet from communicator.
I've passed a text file with the same string you posted here with CRLF on address, and it was saved exactly as shown in the ADIF.

The only thing that could "interact" with this part is the pass-through into the data refresh function, that reads data from qrz.com/hamqth and could fill blank fields with data provided from external source, but doesn't change anything if this is provided in the adif.

I've now added a debug write on the ADDQSO function Log4OM side, that will print the ADIF string received from external in INFO mode (previously was saved only when log level is set to DEBUG in Log4OM main application.

I'll made some more checks...