On 12/05/2020 07:22, HamApps Support
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
thanks for that, the online lookups are most probably the issue
as I have a WiFi connection in the shack which is a bit QRP. No
problem on the issues with implementing a "Retry" button, I had
assumed that as the failure message doesn't time out that the
required code to retry the logbook lookup was easily accessible,
but if that is not the case I fully understand the issues. Since
no one else has chipped in with similar requests, I am fine with
just clearing the B4 cache when this happens. Normally it is
pretty obvious where a station is running a frequency and
continues to call after a QSO, I have to be pretty distracted not
to notice that I have just worked them.