|
2015-01-07 14:37
|
2015-01-07_12-24-17.png (22,087 bytes) |
|
|
0002632 was the root cause of this issue. Once Logbook correctly handles the Unicode encoding from QRZ, it manages non-ASCII characters fine. I'm surprised that it's true, but I've verified with the excellent repro steps provided here that, in current builds, communication between DM780 and Logbook maintains the Unicode encoding and the desired accented character appears in a DM780 lookup of F5JD's info. |
|
|
This doesn't look correct to me. When looking up F5JD with the test function in Callsign Lookup, the name comes back correctly as "<Fname>José</Fname>"... but it's displayed as "Josĉ Dumoulin" |
|
|
Still exists in the 943 release. Changing the status back to assigned |
|
|
AccentAigu.png (16,018 bytes) |
|
|
I assume that "943" really means "843". The issue as described doesn't repro for me. In DM-780, I see "José DUMOULIN" as expected. |
|
|
In Chat, WA9PIE reported that he can always reproduce this issue. With that information, we need to focus on how you his settings or configuration might be different. Here are some relevant questions: Have you tried reproducing the issue with other callsigns? Does the issue affect only the name field, or the address information, too? Any other fields? Do you have multiple sources for callsign resolution configured? Which one is being used to satisfy the erroneous lookup in your repro case? Is it possible that the misspelled name is in your logbook, and it's not actually coming from QRZ? |
|
|
I think the primary configuration setting to focus on are the Callsign Lookup settings in the logbook. The repro steps here don't mention them, and don't mention the state of the logbook database in use when the repro steps are executed. If the Callsign Lookup settings in the Logbook consider previous QSOs in the Logbook, and the used database has an entry for the callsign being retrieved, the entry from the Logbook database is used. If no Logbook database entry is a match, then other sources are considered in the order that they're configured in the Logbook Callsign Lookup settings. The default Callsign Lookup settings are shown below. We can see the Logbook database is used first, then the Country List (?), then the QRZ.com settings. The assumption in this bug is that correct data is retrieved from QRZ, but the accents lost due to a bug in character translation in the Logbook (or between the Logbook and Digital Master) and the accented characters are lost. I contend that representation translations in the Logbook's code were a problem, but have since been fixed; and further that this issue appears to reproduce when it's really just getting bad data previously stored in the Logbook database. Let's demonstrate that scenario with some very specific repro steps. 1) Start up the Logbook 2) Configure only a new database. No otehr databases should be configured; that is, not only not opened, but not set up for the logbook to open. 3) Use the "Callsign Lookup" command to edit the Callsign Lookup settings so that the methods enabled match the defaults shown in the attached screenshot. 4) In the Empty database, use the ALE to add a new entry 5) In the ALE window, enter the callsign "F5JD". Press TAB (or click the "Lookup" button) to lookup the callsign. At this point, the database is empty, so the lookup will end up being resolved by QRZ. Note that the lookup correctly finds "Jose", with accent aigu on the E. 6) Before saving the entry, edit it so that Jose's name is incorrectly spelled. I guess we could make it exactly match the c-circumflex reported here, but it's easy enough to enter "Josxxx". Remember to edit Jose's mailing address on the "Location" tab, too. When you're done, the ALE should look something like the attached screen shot (with different dates and times) 7) Press "add" to save that entry 8) Start DM780 9) Get the ALE in DM780 open. 10) Enter Jose's callsign, "F5JD", and press TAB to look it up. 11) At this point, you'll find that DM780 has retrieved "Josxxx" from the Logbook. The Logbook had the result locally, and never went to QRZ, since that's exactly what it is configured to do. Thus, in order to falsely repro this issue, I think we can conclude that the user's database must have had an entry in it with Jose's name mispelled and that entry satisfied the DM780 lookup request, just as demonstrated here.
CallsignLookupConfig.png (26,165 bytes) |
|
|
JoseXXX.png (44,659 bytes) |
|
|
My previous note said it was not fixed in the "943" build. That was a typo and should have been "843" build. I didn't edit the comment because it changes the date/time of all subsequent comments. But I just tested this on the 846 build and the problem has been fixed. |
- Anonymous
