Invalid gridsquare in main UI

V2 error reports
Post Reply
NS8K
Advanced Class
Posts: 61
Joined: 29 Oct 2017, 12:54

Invalid gridsquare in main UI

Post by NS8K »

Please forgive me if this has been reported. I'm one of the unfortunates who cannot search the forum.

If you key in a call on the main UI and pause while typing, Log4OM will complete a lookup (if what was keyed in is a valid call) and fill in the appropriate information. If you then continue typing to complete the call, another lookup will be done and new information will be filled in EXCEPT for the grid square. It will remain what it was from the initial lookup which would most likely be incorrect.

To follow what I'm talking about, key in N8I then pause for a second or two then key in Y then pause again then key in G. All three calls are valid but you will notice the grid square will remain EN66qd. That's valid for N8I but neither N8IY or N8IYG. If you now backspace one letter at a time and pause after each backspace, you will again see valid lookups occurring but the grid square still remains stuck at EN66qd until you get to only having N8 as the call. This is now an invalid call and a failed lookup will clear the grid square field.

What is causing this behavior is un-checking "Overwrite user gridsquare in main UI" setting under User Preferences. If that setting is checked, it behaves properly. I think the intention of that setting is to leave the gridsquare alone if it is supplied manually or from a program that logs directly like WSJT-X. In this case, gridsquare came from an unintended lookup from typing too slowly or typing an extra character and then backspacing resulting in an incorrect grid square. In my opinion, this is a bug.

Running ver 2.4.0.0 and lookups are via QRZ.com. Win 10 ver 1909.
73 - Tom NS8K
User avatar
KI5IO
Log4OM Alpha Team
Posts: 1798
Joined: 16 Aug 2015, 16:30
Location: Plano, TX

Re: Invalid gridsquare in main UI

Post by KI5IO »

NS8K wrote: 10 Mar 2020, 21:12 Please forgive me if this has been reported. I'm one of the unfortunates who cannot search the forum.

If you key in a call on the main UI and pause while typing, Log4OM will complete a lookup (if what was keyed in is a valid call) and fill in the appropriate information. If you then continue typing to complete the call, another lookup will be done and new information will be filled in EXCEPT for the grid square. It will remain what it was from the initial lookup which would most likely be incorrect.

To follow what I'm talking about, key in N8I then pause for a second or two then key in Y then pause again then key in G. All three calls are valid but you will notice the grid square will remain EN66qd. That's valid for N8I but neither N8IY or N8IYG. If you now backspace one letter at a time and pause after each backspace, you will again see valid lookups occurring but the grid square still remains stuck at EN66qd until you get to only having N8 as the call. This is now an invalid call and a failed lookup will clear the grid square field.

What is causing this behavior is un-checking "Overwrite user gridsquare in main UI" setting under User Preferences. If that setting is checked, it behaves properly. I think the intention of that setting is to leave the gridsquare alone if it is supplied manually or from a program that logs directly like WSJT-X. In this case, gridsquare came from an unintended lookup from typing too slowly or typing an extra character and then backspacing resulting in an incorrect grid square. In my opinion, this is a bug.

Running ver 2.4.0.0 and lookups are via QRZ.com. Win 10 ver 1909.
Tom,

Pls check to see if the most current version of Log4OM V2 has resolved this issue for you.
73 - Nolan Kienitz - KI5IO
Plano, TX
User avatar
G4POP
Log4OM Alpha Team
Posts: 10748
Joined: 21 Jan 2013, 14:55
Location: Burnham on Crouch, Essex UK

Re: Invalid gridsquare in main UI

Post by G4POP »

NS8K wrote: 10 Mar 2020, 21:12 Please forgive me if this has been reported. I'm one of the unfortunates who cannot search the forum.

If you key in a call on the main UI and pause while typing, Log4OM will complete a lookup (if what was keyed in is a valid call) and fill in the appropriate information. If you then continue typing to complete the call, another lookup will be done and new information will be filled in EXCEPT for the grid square. It will remain what it was from the initial lookup which would most likely be incorrect.

To follow what I'm talking about, key in N8I then pause for a second or two then key in Y then pause again then key in G. All three calls are valid but you will notice the grid square will remain EN66qd. That's valid for N8I but neither N8IY or N8IYG. If you now backspace one letter at a time and pause after each backspace, you will again see valid lookups occurring but the grid square still remains stuck at EN66qd until you get to only having N8 as the call. This is now an invalid call and a failed lookup will clear the grid square field.

What is causing this behavior is un-checking "Overwrite user gridsquare in main UI" setting under User Preferences. If that setting is checked, it behaves properly. I think the intention of that setting is to leave the gridsquare alone if it is supplied manually or from a program that logs directly like WSJT-X. In this case, gridsquare came from an unintended lookup from typing too slowly or typing an extra character and then backspacing resulting in an incorrect grid square. In my opinion, this is a bug.

Running ver 2.4.0.0 and lookups are via QRZ.com. Win 10 ver 1909.
You need to update Log4OM, lots of changes since 2.4.0.0
73 Terry G4POP
User avatar
IW3HMH
Site Admin
Posts: 2925
Joined: 21 Jan 2013, 14:20
Location: Quarto d'Altino - Venezia (ITA)
Contact:

Re: Invalid gridsquare in main UI

Post by IW3HMH »

Updating to latest versions is always advised.
Anyway you find the right spot in the option flag.

Log4OM will not change the gridsquare manually inserted (or the gridsquare that is already filled, if the option is set) because you may have set this field during a previous passage of the other station, while you still are trying to catch the right callsign.
It's a win-win choice, as you may face both situations, and log4om cannot know what is the real situation you're facing on.

Once written on the interface, after a lookup, there is no way to detect if the locator was written by a previous lookup or manually as the retrieved information are not persisted to take care of this situation, so Log4OM cannot know who wrote that.
Daniele Pistollato - IW3HMH
NS8K
Advanced Class
Posts: 61
Joined: 29 Oct 2017, 12:54

Re: Invalid gridsquare in main UI

Post by NS8K »

KI5IO wrote: 06 Jun 2020, 02:58 Pls check to see if the most current version of Log4OM V2 has resolved this issue for you.
Nolan / Terry / Daniele

I am now running ver 2.8 and the issue remains the same. Daniele's explanation shows he understands exactly what is happening. Once something ends up in the gridsquare field, you cannot tell if it was keyed by a user, came from an external program or resulted from a lookup. If the source of the gridsquare is from the user or an external program, this feature works perfectly and I use it all the time because I use WSJT-X/JTAlert which supplies the gridsquare from what was transmitted over the air which may or may not be the same as the results of a lookup.

However, if the source of the gridsquare entry is a lookup, I do not think it should remain stuck in that field. The result can be an invalid gridsquare in the QSO record caused by 2 consecutive valid lookups. Daniele understands that the source of whatever is in the gridsquare field is unknown. It is just there, however it got there.

One way to fix this problem would be to have another field associated with gridsquare and that field would be gridsquare source. When gridsquare is supplied by a lookup, the gridsquare source field would be appropriately set so that on another lookup, the programmer would know to replace the gridsquare field contents with the new lookup value. Any other source for the value in gridsquare (external program of keyed by operator) would not set the gridsquare source field and whatever is in gridsquare would remain (just as it does now). Of course, once gridsquare is cleared of any value, the gridsquare source field would also be cleared.

My opinion is that this issue should be fixed to eliminate invalid gridsquares being recorded. I understand this would not be a common occurrence but it can and will happen. As mentioned in the OP, it only works this way if you un-select the option "Overwrite user gridsquare in main UI".
73 - Tom NS8K
NS8K
Advanced Class
Posts: 61
Joined: 29 Oct 2017, 12:54

Re: Invalid gridsquare in main UI

Post by NS8K »

Tonight I discovered another way this issue can affect log entry. Here's a screenshot of callsign K0AF.
K0AF.png
K0AF.png (8.18 KiB) Viewed 4406 times
Note the gridsquare.
Now if I fail to work him and hear N7ZZ, I might select the original call like this:
K0AF2.png
K0AF2.png (8.31 KiB) Viewed 4406 times
And key in the new call.
N7ZZ.png
N7ZZ.png (8.25 KiB) Viewed 4406 times
The result is an incorrect gridsquare in the log entry. N7ZZ should be EN64bo.
73 - Tom NS8K
User avatar
G4POP
Log4OM Alpha Team
Posts: 10748
Joined: 21 Jan 2013, 14:55
Location: Burnham on Crouch, Essex UK

Re: Invalid gridsquare in main UI

Post by G4POP »

If you fail to work the call the correct way to clear the fields is to use the clear (X) button or press Esc on your keyboard
73 Terry G4POP
f4flq
Novice Class
Posts: 13
Joined: 21 Sep 2016, 06:58

Re: Invalid gridsquare in main UI

Post by f4flq »

Good evening
There is the same problem during QSO in FT8 in general the locator is sent on 4 characters.
If you edit the QSO and you update via "refresh data" the locator remains on 4 characters,
however if you delete the entry with the update the locator is then updated with 6 characters.
Best 73
Manu F4FLQ
User avatar
G4POP
Log4OM Alpha Team
Posts: 10748
Joined: 21 Jan 2013, 14:55
Location: Burnham on Crouch, Essex UK

Re: Invalid gridsquare in main UI

Post by G4POP »

f4flq wrote: 23 Jul 2020, 22:35 Good evening
There is the same problem during QSO in FT8 in general the locator is sent on 4 characters.
If you edit the QSO and you update via "refresh data" the locator remains on 4 characters,
however if you delete the entry with the update the locator is then updated with 6 characters.
Best 73
Manu F4FLQ
This is by design so that data that already exists is not overwritten

The reason? Because the user often inserts data provided by the other station which is probably more accurate than that provided by on line lookups
73 Terry G4POP
f4flq
Novice Class
Posts: 13
Joined: 21 Sep 2016, 06:58

Re: Invalid gridsquare in main UI

Post by f4flq »

Yes, for sure, but wouldn't it be possible to check it?
If the locator is JN25 and during the update I have JN25rh so it is just more precise.
Cordially
Post Reply