A log I created via HAMRS a few days ago included a column with my grid listed in the adif file. A log today did not. These both used the same version of HAMRS. A few other columns were rearranged.
Any ideas why that may have happened?
Is “My Grid” entered in one or more of the QSO entries in your HAMRS log?
If not, the exported ADIF wouldn’t include the MY_GRIDSQUARE. If any of the QSOs have that field populated, then the column will be exported with the file.
Note that you won’t see your grid square in HAMRS unless expanded mode is turned on in the Settings menu.
What’s the move here? Should I not worry about making the grid field ‘live’? make it more static? For example, when you click New Logbook and choose the POTA template from the drop down, show fields for park, grid etc right then and just be done with it? Apply those to every QSO in the logbook? I definitely feel like I’m missing something here as this comes up quite a bit and I think it was me missing how most people would use logbooks right out of the gate when I first wrote HAMRS
Jarrett, I don’t know that anything needs to be done. I didn’t think I had been putting my grid location in while using the POTA template, so didn’t this time. I can certainly do that. I merely thought something had changed.
I so appreciate all you have put into this. I always check my files in ADIF Master in case I did miss something, and noticed the whole column of MY_GRIDSQUARE missing. It’s an easy fix on my end if I set up my template correctly.
73, Steve/KB9CNN
@Jarrett I wouldn’t move the QTH/location fields to the profile, but the end user DOES need the ability to choose whether to (1) apply them to the entire log, or (2) keep the QTH/location fields as “sticky.”
Most users will (or must, per POTA rules) maintain one log per park. But the location fields can change, particularly if someone decides to activate a large park and moves between locations in that park.
I’ve recommended this before and will suggest it again:
-
Add to the Frequency / call / park / grid square panel a vertical scroll bar and add the remaining location fields that are otherwise inaccessible (my state, my city, my county). At present, one has to edit the first QSO to enter these other fields, and those fields are not “sticky” – they don’t get transferred to subsequent QSOs.
-
By default, make the current location data for the activator “sticky,” such that every QSO after entering these data will replicate them. This way, if I do half of my QSOs for the park at one location, then change locations within the same park – perhaps to another county or grid square – I can then change these fields and they will be replicated for every subsequent QSO.
-
Give the option to replicate the location data to every QSO entry in the log. Just like you have a gear symbol next to each QSO record that has a pop-up to “Lookup all,” you could put a gear symbol next to each of the location fields in 1. above (my grid, my state, my QTH, and my county, which are visible in the scrollable window) that gives an “Apply to all” option. That way, if I enter an incorrect grid square, county, etc. at the beginning, I can correct all QSOs to match the correct location info with the press of a single button. Otherwise, I need to go back and edit each and every QSO that contains the wrong data in these fields.
That’s my 2 cents… ask if you need clarification.
Thank you,
Kevin KZ3L
This, in my opinion, is a very good idea indeed. Good catch KZ3L. Thanks Jarrett, WD4T
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.