Grid Locator Erasure

[dk2lo]

During the last Es openings on 6m I experienced the following:

You copy a station which is in QSO and you already got his locator. When you get in QSO with him and enter his callsign the grid field is empty, just erased. I f you are not aware of this the QSO is saved witout the locator information. The same happens also when you correct parts of the callsign. E. g. you have copied PB3FUN and correct this to PB4FUN. Also then the Grid Field is erased.

I now write the grid informations on a piece of paper and enter them at the end of the QSO when the call is sure. But I really dont like this paperwork when i have logging program.

I would suggest, that QSO informations already copied and logged are only erased by using the clear button.

[PB4FUN]

Are you sure this should be in Feature suggestions ?
This would be more an issue for bug reports

[IW3HMH]

I'm accurately reading that thread...
but preventing grid square from being deleted when you change callsign or other could create more troubles than the troubles that fixes.
There is the concrete possibility that you change the callsign and the previous callsign (that was already looked up on QRZ) will leave his gridsquare in the gridsquare box. In that case you will save the WRONG locator with the QSO.

This is not a bug, or if it's a bug the same concept should be extended for every field in the qso entry area... if you write a callsign not present in QRZ/HAMQTH the fields will remain filled or, in the worst case, filled with existing informations while the non-existing informations from QRZ/HAMQTH are the ones from the previous lookup...

[PB4FUN]

If you have not logged the QSO and change callsign, yes.
But if you edit it there should be at least a possibility to prevent it from being erased.
Maybe you should add a confirmbox on the validate event of the callsignbox where you ask the user if he wants to clear the grid (and maybe other fields) (yes=> clear; no =>keep; cancel => editcallsign.focus )

Sometimes it happens when you make a QSO and fill in the callsign wrong (some hams have no rhythm using CW) and the rest of all fields is correct. Than you receive a QSL from eQSL with that exact time, freq but instead of the XY1AB it is XY1ATS. That should not be the reason to clear other fields. Or should I use update queries instead to keep those values ?

[IW3HMH]

log4om makes a dynamic search on callsigns.
1) you hear my call and type -> IW3HM....... listening for last char...
2) in the meanwhile you type my grid locator JN65EO
3) at the same time (before or later) log4om does the QRZ lookup for IW3HM that retrieves Stefano Ottavian, that is a friend of mine, living 50km North from here and fills all info's including the locator
4) you type the last H of my callsign

at this point log4om should:
1) keep all informations (related to IW3HM) because you probably have manually added the locator
2) refresh all informations using QRZ data

in SOME cases the right thing to do is keeping all the info's, in other cases the callsign is changed, and the data retrieved from web are not valid, locator included. Asking you "do you want to keep the data" between every single character typed in callsign box (or added lately) is a not functional solution. Asking the same if the callsign has been retrieved from QRZ is also a non functional solution (if you're not fast enough it will make several lookups before you type the full callsign)

I still don't see how we can do that, without annoying popups... it's not lack of time or anything else... it's something that is not streamlined with the "most used" user case.

[dk2lo]

Hi Daniele,

thank you very much for looking at this thread.

I suspected that this behavior is a feature and not a bug.

It is a bit philosophical but here are my thougths:

I as a user would like to always have the full control about my data. So a program should never change or erase any data I have delivered. It could suggest a change, but should only take this suggestion when the user confirms this. If the user does not push a confirm button everything should be taken as it is also with any errors assumed by the software.

If I need to drop a callsign because the QSO could not be made I use the "CLEAR" button so that everything is still in full control.

I am not a QRZ subscriber, so I dont get any locator informations from this source. I am also often working with Internet offline, because my location has a very limited internet connectivity. But nevertheless also offline databases if available can be wrong. Only what I hear and copy I would like to log.

Here is an example for exact logging and wrong informations from QRZ. Last year I worked in a contest a station who gave me as multiplier MO. Because I still needed MO on this band for WAS I was happy. QRZ said unfortunately that this station was from a state I did not need. Later my Google search showed that this callsign actually was operated from a contest location in MO. So QRZ information was wrong for this event and I was happy again.

Also a callsign can be used from different locators in the same DXCC entity by using remote stations or real locations. Then QRZ or other databases are not sufficient or reliable. Again it only counts what the operator tells me.

I dont know how the algorithm works. But by testing I found that changes at the end of the callsign get different results than changes in the middle or the beginning. I would like to show an example: I am not a good CW operator and sometimes have problems especially with numbers. I also do mistypes. E. g. I copy IW4HMH on 6m and get his locator. In the QSO my partner corrects his callsign to IW3HMH. When I change the wrong number 4 to the right 3 the locator field is suddenly empty. No error message or something else tells my about this data loss. I experienced this behaviour now several times in the current 6m Es season and I really dont like it because I lost locator informations.

I would appreciate that this "auto-erase feature" can be switched off in the configuration for users who dont like it.


Daniele thank you very much for a great software!

[IW3HMH]

Ok i got the point Olaf.
I should think about, because there are a couple of things that works behind the scenes...
but yes, for "disconnected" operations we can provide this kind of option

[dk2lo]

Thank you very much Daniele!

This is only a very small issue in a great software product. It just came up in the current 6m Es season and does not hurt on the other HF bands.

Hope to see you soon on the HAMRADIO in Friedrichshafen for an eyeball QSO.