Invalid gridsquare in main UI

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

Invalid gridsquare in main UI

Post by NS8K » 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.
73 - Tom NS8K

User avatar
KI5IO
Log4OM Alpha Team
Posts: 590
Joined: 16 Aug 2015, 16:30

Re: Invalid gridsquare in main UI

Post by KI5IO » 06 Jun 2020, 02:58

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: 7163
Joined: 21 Jan 2013, 14:55
Location: Burnham on Crouch, Essex UK

Re: Invalid gridsquare in main UI

Post by G4POP » 06 Jun 2020, 06:55

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: 2643
Joined: 21 Jan 2013, 14:20
Location: Quarto d'Altino - Venezia (ITA)
Contact:

Re: Invalid gridsquare in main UI

Post by IW3HMH » 08 Jun 2020, 13:21

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

Post Reply