locked Re: Logging failures do not update worked before information


HamApps Support (VK3AMA)
 

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.

73
Bill
G4WJS

Bill,

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

Join Support@HamApps.groups.io to automatically receive all group messages.