toggle quoted messageShow quoted text
Laurie, I don't know about a Retry, but seems it might be possible. There is the Last QSO Log that it tells us it's there. I have stumbled around in the past and somehow got it to get it back in the log. Usually it's easier for me to just enter the info into the log from the still visible screen, but I can't remember how to retrieve it from the Last QSO Log, but that's gotta be a clue for a Retry. Thanks again. 73 Herb WB8ASI Can't sleep.
On May 12, 2020 at 2:22 AM "HamApps Support (VK3AMA)" <vk3ama.ham.apps@...> wrote:
On 11/05/2020 9:37 pm, g4wjs wrote:
I am using DXKeeper for logging. My delay before checking is set to 8 seconds which is perfectly adequate 99% or more of the time, but occasionally when my machine is particularly busy it trips up. Thanks for the tip on clearing the B4 cache. How about my suggestion of a "Retry" button alongside the "Ok" button on the error message about not confirming the logging success, in my case that would cover all the cases as far as I know, assuming a successful retry that finds the logged QSO goes on to update the worked B4 cache in JTAlert.
Do you have DXKeeper set to auto-upload new QSOs to one or more online-logbooks? If so, that is a likely cause of the occasional extended logging times. That has been experience by JTAlert/DXKeeper users in the past.
Regarding a "Retry" button, that would seem to be the most sensible if it wasn't' for the code I have to work with. All the logging code is in the main JTAlert executable and runs on the UI thread. A Retry will involve a database access and a timeout value (if the lookup was unsuccessful), both of which will block the main thread. I am hesitant to add further blocking code. I will give it some thought.
de Laurie VK3AMA