View Issue Details

IDProjectCategoryView StatusLast Update
0003554Ham Radio DeluxeBugpublic2020-02-04 23:48
Reporterg3ucqAssigned ToWA9PIE 
Status closedResolutionfixed 
PlatformPCOSWindowsOS Version10 64 bit Home
Product Version 
Target VersionFixed in Version6.7.0.262 
Summary0003554: The Logbook Lookup can stop responding
DescriptionWith enabled as a Lookup the Lookup pane stops responding and closes the Logbook.
Steps To ReproduceLoad the Logbook only.
It seems to make no difference whether Rig Control is running or not.
In Logbook/Tools/Configure/Callsign Lookup add only to the Enabled Methods so you have Public and Private UCSDB, and Country List.
Open the Lookup pane and enter a callsign e.g. KH0A.
The data is populated.
Press the Reset button to clear the data and enter another callsign.
The data is populated but soon it is not possible to resize the Lookup pane window and the Logbook stops responding.
Additional InformationThis happens with 2 Windows 10 64 bit OS.
As far as I can tell, this only happens with selected in the Callsign lookup option.
Tags6.7 defects
Sub-ModuleCall lookup
Testing Beta Successful



2019-11-06 05:26

developer   ~0009164

A minidump would be helpful.


2019-11-06 05:29

viewer   ~0009166

Sorry. A mini dump is not created, at least there no message telling me one has.


2019-11-06 05:38

developer   ~0009167

Minidumps are automatically created for crashes, not for hangs. Please create a minidump manually.


2019-11-06 06:00

viewer   ~0009168

I have done that Mike but even zipped the file is 164Mb.
I changed to Small dump but that is still the same size.
My limit here is 2MB. It used to be much more.


2019-11-06 06:10

developer   ~0009170

Please contact MikeC about the file limit, as it's not within my control.


2019-11-06 08:43

viewer   ~0009175

MikeB. I have put into the Dropbox
Dropbox/Ham Radio Deluxe (1)/HRD Beta Team/
Hope that is OK.


2019-11-06 09:50

viewer   ~0009176

Well this is a bit odd.
Firstly, I can replicate the issue by using the steps in "steps to reproduce" but ONLY if the callsign in the lookup box is KH0A.
Opening logbook and trying several known callsigns there is no crash.
As soon as I press reset after loading KH0A then logbook becomes unresponsive.
I have repeated this several times with the same result.
I have uploaded a dump file to dropbox HRD Beta team folder


2019-11-06 10:54

viewer   ~0009177

I am beginning to think that this issue is related to resizing the Lookup window and the use of the slider on the right but cannot find the right sequence.


2019-11-06 13:17

administrator   ~0009178

Last edited: 2019-11-06 13:20

View 2 revisions

I have experimented with the KH0A callsign in the Lookup Pane and it pulls it every time with no problem. I have my Lookup options configured,
Public UCSDB
Private UCSDB
Logbook Sugscription
Country List

I've also tried swapping the Logbook and positions and it still works fine with any call I put in. Clearing calls with the "Reset" button and entering a new call doesn't cause any problems either.


2019-11-06 13:39

viewer   ~0009179

same as with Tim, I can't Replicate


2019-11-06 14:36

viewer   ~0009180

Having added Logbook to the Lookup options the Lookup pane now stops responding every time, or the Logbook does so have uploaded another minidump file to the Dropbox. G3UCQ_HRDLogbook (2).zip


2019-11-06 15:00

viewer   ~0009181

I think this relates to the size of the Lookup pane window when it is started.
Open the window and drag it large enough so that the vertical slider will not be visible.
Add a callsign, the data will be populated, repeat as many times as you like and there is no problem.
Reset the Lookup pane and close it and then reopen it.
Now, reduce the size of the pane so that the vertical slider will be active.
Add a callsign, the pane is populated but try to move the slider.
This is when the Logbook stops responding for me, every time.


2019-11-07 04:42

viewer   ~0009189

I've been puzzling as to why only John and I are seeing the logbook crashes on lookup.
I noticed that my "Use Case" may be uncommon in that I have 2 logbooks open at any one time. One local access mdb and one MySQL database accessed through ODBC.

Sure enough, I closed the second logbook to leave only the MySQL logbook open. No crashes at all. Dozens of tests - no crashes.
Opened the second logbook - crashed on the first lookup of KH0A. There we go.


2019-11-07 04:55

viewer   ~0009190

It is a puzzle. I have only one logbook open.
This morning, try as I might, I could not get the Lookup pane to cause a crash.
Now loaded Logbook again and it stops responding with KH0A. Weird!
I hope the minidumps point to the cause.


2019-11-07 08:03

developer   ~0009191

I don't have access to Dropbox, so I can't obtain the minidump files.


2019-11-07 08:15

viewer   ~0009192

Can I email mine?


2019-11-07 08:29

developer   ~0009194

It seems better to get in touch with MikeC so he can fix the problem with Mantis not accepting files. It's very valuable to have all the information related to a particular issue in one place. Remember, my perspective is a little different than yours: I need to keep track of hundreds of different Mantis reports and make progress on all of them (sooner or later). Shuffling around between Google Drive, DropBox, email, and ... is a complication we should work to eliminate.


2019-11-07 10:12

developer   ~0009198

I've tried this:

1) Single logbook open; local Access DB
2) QRZ is the only additional lookup source
3) Sqush logbook window vertically so scroll bar is necessary in Lookup pane
4) Lookup KH0A
5) No problem.

And this:

1) Single logbook open; local Access DB
2) QRZ and Logbook are the only additional lookup sources, in that order
3) Sqush logbook window vertically so scroll bar is necessary in Lookup pane
4) Lookup KH0A
5) No problem.

Then this:

1) Single logbook open; local Access DB
2) Logbook and QRZ are the only additional lookup sources, in that order
3) Sqush logbook window vertically so scroll bar is necessary in Lookup pane
4) Lookup KH0A
5) No problem.

And also this:

1) Two logbook databases open; local Access DB and remote MySQL DB
2) QRZ is the only additional lookup sources, in that order
3) Sqush logbook window vertically so scroll bar is necessary in Lookup pane
4) Lookup KH0A
5) No problem.

As well as this:

1) Two logbook databases open; local Access DB and remote MySQL DB
2) QRZ and Logbook are the only additional lookup sources, in that order
3) Sqush logbook window vertically so scroll bar is necessary in Lookup pane
4) Lookup KH0A
5) No problem.

Plus this:

1) Two logbook databases open; local Access DB and remote MySQL DB
2) QRZ and Logbook are the only additional lookup sources, in that order
3) Sqush logbook window vertically so scroll bar is necessary in Lookup pane
4) Lookup KH0A
5) No problem.

While I don't doubt that ya'll are experiencing a problem, I've been poking around at it for a couple of hours now and can't demonstrate the behaviour. Without access to more information, I don't think I'll be able to isolate the issue well enough to find a cause.

If you have any other hints or descriptions, I'm happy to receive them. I also strongly encourage you to get in touch with MikeC to ask him to resolve the issues you're having with Mantis -- they're entirely beyond my control, and solving them would help fix not only this issue, but any other issue which would be aided by the attachment of a dump file (or any other large media file).


2019-11-07 10:20

viewer   ~0009199

Noted. I'll email Mike about getting the dump files to you. I agree about keeping everything in one place ie mantis.
I've had several crashes this afternoon during "normal operating".
I'll keep looking for clues.


2019-11-07 11:34

viewer   ~0009200

Mike, G3YPP I have already emailed Mike C.
I am sure this is related to the Lookup pane window size.
See my note 9189.


2019-11-07 11:36

viewer   ~0009201

9181. Sorry.


2019-11-07 22:00

developer   ~0009202

My repro in 9198 uses a short window which requires a vertical scroll bar. The issue doesn't reproduce.


2019-11-08 08:41

viewer   ~0009211

This is still happening with me in the public release
But this last time a minidump was created when I entered the callsign W4CI
Is there a clue in here?
I also have several dump files that are too large to upload here.

HRDLogbook_20191108_143646.mdmp (596,124 bytes)


2019-11-09 10:03

viewer   ~0009213

Strange. Now I have installed my issues with the lookup pane have ended.


2019-11-09 10:39

viewer   ~0009214

I loaded _244. WIth QRZ look-up selected as a lookup option, it reads and populates the ALE fields properly, but then wehn I go to loog the call into he Log Book or try to look up another call, LogBook hangs. When I remove QRZ look up, does not hang.
SO even with a _244 download, still have the same problem...
Pete W2PJ


2019-11-09 10:59

viewer   ~0009215

Pete. Shot in the dark. But if this could be a Windows thing, do you have Windows 10 update KB 4519573 installed?
If not, it might be worth trying.


2019-11-09 11:26

viewer   ~0009216

In version _244, selecting any call from the DX Cluster window resulted in 1 proper look up, and then Logbook hangs on that first call...
Pete - W2PJ.


2019-11-09 12:29

viewer   ~0009217

G3UCQ - What is Windows 10 update KB 4519573 installed? I do not see it in my most recent updates in "View Update History" on my computer. There are other updates but not that specific one... How else can I tell if it s installed, or where can I get it and install it?


2019-11-09 12:45

viewer   ~0009218

G3UQC - I checked and I have a different update ( newer?) installed? October 8, 2019-KB4524100 Cumulative Update for .NET Framework 3.5 and 4.8 for Windows 10 Version 1903 and Windows Server 1903 RTM?


2019-11-09 13:26

developer   ~0009219

I think that the dump provided by G3YPP captures the issue. The crash is caused by the main thread trying to pass messages around while the application is shutting down:

0:000> .ecxr
eax=01255998 ebx=025fba38 ecx=11c1b6d8 edx=02372000 esi=00000010 edi=00000000
eip=00000010 esp=021ffad0 ebp=021ffb40 iopl=0         nv up ei pl nz na pe nc
cs=0023  ss=002b  ds=002b  es=002b  fs=0053  gs=002b             efl=00210206
00000010 ??              ???
0:000> kb
  *** Stack trace for last set context - .thread/.cxr resets it
 # ChildEBP RetAddr  Args to Child              
WARNING: Frame IP not in any known module. Following frames may be wrong.
00 021ffacc 00a93500 00000363 00000001 00000000 0x10
01 021ffb40 00a97c61 11c1b6d8 004c004f 00000363 HRDLogbook!AfxCallWndProc+0xc6 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 268] 
02 021ffb60 00a97c99 00030b7c 00000363 00000001 HRDLogbook!CWnd::SendMessageToDescendants+0x31 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3025] 
03 021ffb84 00a97c99 000b0b3c 00000363 00000001 HRDLogbook!CWnd::SendMessageToDescendants+0x69 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3013] 
04 021ffba8 00a97c99 0025078e 00000363 00000001 HRDLogbook!CWnd::SendMessageToDescendants+0x69 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3013] 
05 021ffbcc 00a9e1bf 00100788 00000363 00000001 HRDLogbook!CWnd::SendMessageToDescendants+0x69 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\wincore.cpp @ 3013] 
06 (Inline) -------- -------- -------- -------- HRDLogbook!CWnd::SendMessageToDescendants+0xe [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\include\afxwin2.inl @ 129] 
07 021ffbf8 00a9e424 00000000 012a88f0 00ac8063 HRDLogbook!CWinThread::OnIdle+0x4d [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 680] 
08 021ffc18 00fb7a77 00000000 014c3b98 0236f000 HRDLogbook!CWinThread::Run+0x44 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\thrdcore.cpp @ 621] 
09 021ffc30 00bf1463 00700000 00000000 02581de8 HRDLogbook!AfxWinMain+0x93 [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winmain.cpp @ 61] 
0a (Inline) -------- -------- -------- -------- HRDLogbook!invoke_main+0x1a [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 118] 
0b 021ffc7c 76126359 0236f000 76126340 021ffce8 HRDLogbook!__scrt_common_main_seh+0xf8 [d:\agent\_work\3\s\src\vctools\crt\vcstartup\src\startup\exe_common.inl @ 288] 
0c 021ffc8c 77a17b74 0236f000 27309ff3 00000000 kernel32!BaseThreadInitThunk+0x19
0d 021ffce8 77a17b44 ffffffff 77a38f0f 00000000 ntdll!__RtlUserThreadStart+0x2f
0e 021ffcf8 00000000 00bf14e7 0236f000 00000000 ntdll!_RtlUserThreadStart+0x1b

If we dig around in the other threads, we can find one that's trying to write a minidump but can't, since the app is being closed. But we also find a thread that's handling the results from the call sign lookup operation in the lookup pane:

0:000> ~*kb
   6  Id: a18.1db4 Suspend: 0 Teb: 0238a000 Unfrozen
 # ChildEBP RetAddr  Args to Child              
00 09c3f8e0 00a92f04 00030b7c 00000000 00000000 win32u!NtUserSetWindowPos+0xc
01 09c3f908 00c32c3d 012a0b50 00000000 00000000 HRDLogbook!CWnd::SetWindowPos+0x2e [d:\agent\_work\3\s\src\vctools\vc7libs\ship\atlmfc\src\mfc\winocc.cpp @ 317] 
02 09c3f92c 00c2a5a6 00000001 00000000 080b4f20 HRDLogbook!CXTPScrollBarContainerImpl::ShowScrollBar+0x7d [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\common\scrollbar\xtpscrollbarcontainer.cpp @ 466] 
03 (Inline) -------- -------- -------- -------- HRDLogbook!CXTPScrollBarContainer<CWnd>::ShowScrollBar+0xf [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\common\scrollbar\xtpscrollbarcontainer.h @ 177] 
04 09c3f980 00c29a88 5a64ecbc 082e4940 0000000d HRDLogbook!CXTPTaskPanel::UpdateScrollBar+0x146 [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\taskpanel\xtptaskpanel.cpp @ 1339] 
05 09c3fa20 00c2f45e 00000001 00c322d1 09c3fb04 HRDLogbook!CXTPTaskPanel::Reposition+0x1e8 [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\taskpanel\xtptaskpanel.cpp @ 1274] 
06 09c3fa28 00c322d1 09c3fb04 008e24cc 00000000 HRDLogbook!CXTPTaskPanelItem::RepositionPanel+0xe [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\taskpanel\xtptaskpanelitem.cpp @ 258] 
07 09c3fa30 008e24cc 00000000 5a64ed98 0768cfc4 HRDLogbook!CXTPTaskPanelGroupItem::SetBold+0x11 [c:\program files (x86)\codejock software\mfc\xtreme toolkitpro v18.6.0\source\taskpanel\xtptaskpanelgroupitem.cpp @ 131] 
08 09c3fb04 0078e38c 0768ced8 09c3fb28 00854df9 HRDLogbook!CPaneLookup::OnCallsignLookupComponentFinished+0x22c [c:\hrd67\logbook\hrdlogbook\panelookup.cpp @ 1635] 
09 (Inline) -------- -------- -------- -------- HRDLogbook!CCallsignLookupComponent::CheckCompleted+0x16 [c:\hrd67\logbook\hrdlogbook\callsignlookupcomponent.cpp @ 375] 
0a 09c3fb10 00854df9 00000000 129f7398 12966f08 HRDLogbook!CCallsignLookupComponent::LookupResult+0x2c [c:\hrd67\logbook\hrdlogbook\callsignlookupcomponent.cpp @ 332] 
0b 09c3fb28 00854cc8 0768ced8 00000000 002036a4 HRDLogbook!CLibBackgroundProcessingThread::CallsignLookupNew+0xc9 [c:\hrd67\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 562] 
0c (Inline) -------- -------- -------- -------- HRDLogbook!CLibBackgroundProcessingThread::ProcessData+0x2d [c:\hrd67\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 289] 
0d 09c3fb70 009571b6 5a64ed2c 07fb01d8 00957120 HRDLogbook!CLibBackgroundProcessingThread::DoWork+0x98 [c:\hrd67\logbook\hrdlogbook\logbookbackgroundprocessingthread.cpp @ 227] 
0e (Inline) -------- -------- -------- -------- HRDLogbook!CThinThread::Run+0x55 [c:\hrd67\logbook\hrdlogbook\thinthread.cpp @ 188] 
0f 09c3fbb0 00f97010 0768cfc4 5a64ed70 00f96fb9 HRDLogbook!CThinThread::Start+0x96 [c:\hrd67\logbook\hrdlogbook\thinthread.cpp @ 227] 
10 (Inline) -------- -------- -------- -------- HRDLogbook!invoke_thread_procedure+0xd [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 91] 
11 09c3fbec 76126359 07fb01d8 76126340 09c3fc58 HRDLogbook!thread_start<unsigned int (__stdcall*)(void *)>+0x57 [d:\th\minkernel\crts\ucrt\src\appcrt\startup\thread.cpp @ 115] 
12 09c3fbfc 77a17b74 07fb01d8 2cec9f43 00000000 kernel32!BaseThreadInitThunk+0x19
13 09c3fc58 77a17b44 ffffffff 77a38f0f 00000000 ntdll!__RtlUserThreadStart+0x2f
14 09c3fc68 00000000 00f96fb9 07fb01d8 00000000 ntdll!_RtlUserThreadStart+0x1b

The problem is that the results from the lookup operation are handled with a callback function that could be entered on a different thread -- the worker thread that the call sign lookup uses. The handler tries to work with the UI and ends up sending messages performing other blocking manipulations. Since the main thread is blocked on waiting for the call sign lookup to complete, but the call sign lookup won't register completion (and release the main thread) until the main thread responds to the work the handler is trying to do, we end up with a dead lock.

I've decoupled the notification of the completion from the handling of the results so this deadlock should no longer be possible.

Thanks for posting the dump. Even though this issue is solved, I still think it's important to get in touch with MikeC and have him fix the attachment size limit problem in Mantis.


2019-11-09 13:27

developer   ~0009220

The fix described above is made with this checkin:


2019-11-09 14:03

viewer   ~0009222

K7ZCZ: Will an update be posted in the drop box for the Beta group to try out?
Pete - W2PJ


2019-11-10 23:35

viewer   ~0009243

Seems to be working here.
No issue found with


2019-11-11 05:01

administrator   ~0009251

Glad for Ferry's comments... would like to have some beta tester feedback as well.


2019-11-11 05:22

viewer   ~0009252

Certainly, in a few hours Mike.


2019-11-11 06:03

administrator   ~0009256

Feedback from a former beta tester:



It doesn't appear to have improved things.

Received lookup from Subscription for WA9PIE completed in 21.469 seconds


David G4NVB


2019-11-11 06:46

viewer   ~0009257

I have got 2 fixed confirmations via testers


2019-11-11 09:57

viewer   ~0009258

Fixed for me. Good job.


2019-11-11 09:58

viewer   ~0009259

My lookups are instantaneous.


2019-11-11 15:20

administrator   ~0009263

David G4NVB indicates that the lookups take over 20 seconds and... if he hits "Cancel" during the lookup, then Logbook will crash.

Can anyone verify this? (Not exactly sure if it's part of the original report here. We may end up creating a new Mantis for this.)


2019-11-11 18:50

viewer   ~0009268

I just tested revision 245. When I put a call in the lookup window, it appears to no longer lock up immediately. But that LAT LON for USA stations is wrong in google earth LAT LONG readout display. Also there is no licensee information displayed, and if you try to hit Logbook for that call sign, a logbook window opens, but does not see previous contacts (all blank for calls I have worked many times (in either partial or exact mode selected)), and then the logbook immediately freezes, and requires CNTRL-ALT-DELETE to end task. Happens reliably with any call entered in to the lookup window.

Pete W2PJ


2019-11-11 20:54

administrator   ~0009269

Can you give me a screenshot Pete?


2019-11-11 22:20

viewer   ~0009270

Sorry, but I already removed version 245. It took me all night to restore .227. I had to perform a system restore to get HRD stable. Went back to ~NOV 7. The system resore sid it had failed but it obvisouly did not as version .227 was back.

System Restore.PNG (18,016 bytes)
System Restore.PNG (18,016 bytes)


2019-11-12 02:49

viewer   ~0009271

Seems to not work for all
Ticket# 548546
it appears the QRZ issue (impossibly slow matching up of QSLs still exists. I waited about 2-3 minutes and it got to about 350 then I gave up and force closed it.


2019-11-12 02:52



2019-11-12 02:52

viewer   ~0009272

As for David G4NVB, he gave me some info see the attached here and look for the Minidump on Google drive in the related Mantis folder.

HRDLogbookCallsignLookup.txt (2,299 bytes)
Lookup: Public Unique Call: WA9PIE
Received lookup from Public UCSDB for WA9PIE completed in 0.000 seconds
Lookup: Private Unique Call: "WA9PIE"
Lookup: Private Unique Call "WA9PIE" not found
Received lookup from Private UCSDB for WA9PIE completed in 0.000 seconds
Starting lookup from Subscription: WA9PIE
Lookup from Country List: WA9PIE
Received lookup from Country List for WA9PIE completed in 0.000 seconds
Received lookup from Subscription for WA9PIE completed in 21.609 seconds
"Public UCSDB" failed with "Not found"
"Private UCSDB" failed with "Not found"
" Subscription" provided value "Collin" for field "COL_CNTY"
" Subscription" provided value "5" for field "COL_CQZ"
" Subscription" provided value "United States" for field "COL_COUNTRY"
" Subscription" provided value "MICHAEL G CARPER, PhD, WA9PIE\nPO Box 995\nProsper, TX 75078\nUnited States\n" for field "COL_ADDRESS"
" Subscription" provided value "NA" for field "COL_CONT"
" Subscription" provided value "MICHAEL G CARPER, PhD" for field "COL_NAME"
" Subscription" provided value "291" for field "COL_HRDCOUNTRYNO"
" Subscription" provided value "58" for field "COL_AGE"
" Subscription" provided value "Prosper" for field "COL_QTH"
" Subscription" provided value "291" for field "COL_DXCC"
" Subscription" provided value "" for field "COL_EMAIL"
" Subscription" provided value "EM13of" for field "COL_GRIDSQUARE"
" Subscription" provided value "6" for field "COL_ITUZ"
" Subscription" provided value "33.245054" for field "COL_LAT"
" Subscription" provided value "-96.770887" for field "COL_LON"
" Subscription" provided value "TX" for field "COL_STATE"
" Subscription" provided value "WA9PIE" for field "COL_QSL_VIA"
"Country List" provided value "United States" for field "COL_COUNTRY", keeping "United States" from " Subscription"
"Country List" provided value "291" for field "COL_DXCC", keeping "291" from " Subscription"
"Country List" provided value "291" for field "COL_HRDCOUNTRYNO", keeping "291" from " Subscription"
"Country List" provided value "NA" for field "COL_CONT", keeping "NA" from " Subscription"


2019-11-12 03:38

viewer   ~0009273

Pete at 9268. I tried to replicate his issue but, apart from not seeing previous contacts in the ALE Logbook tab, I have not had problems.
(KH0A is shown as the Mariana Islands in the Lookup pane but United States in the ALE)


2019-11-13 05:39

viewer   ~0009293

Working for me in .245.
Instantaneous QRZ lookup


2019-11-16 16:44

administrator   ~0009332


Issue History

Date Modified Username Field Change
2019-11-06 05:20 g3ucq New Issue
2019-11-06 05:26 K7ZCZ Assigned To => g3ucq
2019-11-06 05:26 K7ZCZ Status new => feedback
2019-11-06 05:26 K7ZCZ Note Added: 0009164
2019-11-06 05:29 g3ucq Note Added: 0009166
2019-11-06 05:38 K7ZCZ Note Added: 0009167
2019-11-06 06:00 g3ucq Note Added: 0009168
2019-11-06 06:10 K7ZCZ Note Added: 0009170
2019-11-06 08:43 g3ucq Note Added: 0009175
2019-11-06 09:50 g3ypp Note Added: 0009176
2019-11-06 10:54 g3ucq Note Added: 0009177
2019-11-06 13:17 KB3NPH Note Added: 0009178
2019-11-06 13:20 KB3NPH Note Edited: 0009178 View Revisions
2019-11-06 13:39 PD9FER Note Added: 0009179
2019-11-06 14:36 g3ucq Note Added: 0009180
2019-11-06 15:00 g3ucq Note Added: 0009181
2019-11-06 16:17 WA9PIE Project 2 - Next Dev List (Holding Area) => 3 - Current Dev List
2019-11-07 04:42 g3ypp Note Added: 0009189
2019-11-07 04:55 g3ucq Note Added: 0009190
2019-11-07 08:03 K7ZCZ Note Added: 0009191
2019-11-07 08:15 g3ucq Note Added: 0009192
2019-11-07 08:29 K7ZCZ Note Added: 0009194
2019-11-07 10:12 K7ZCZ Note Added: 0009198
2019-11-07 10:20 g3ypp Note Added: 0009199
2019-11-07 11:34 g3ucq Note Added: 0009200
2019-11-07 11:36 g3ucq Note Added: 0009201
2019-11-07 22:00 K7ZCZ Note Added: 0009202
2019-11-08 08:41 g3ypp File Added: HRDLogbook_20191108_143646.mdmp
2019-11-08 08:41 g3ypp Note Added: 0009211
2019-11-09 10:03 g3ucq Note Added: 0009213
2019-11-09 10:39 w2pj Note Added: 0009214
2019-11-09 10:59 g3ucq Note Added: 0009215
2019-11-09 11:26 w2pj Note Added: 0009216
2019-11-09 12:29 w2pj Note Added: 0009217
2019-11-09 12:45 w2pj Note Added: 0009218
2019-11-09 13:26 K7ZCZ Note Added: 0009219
2019-11-09 13:27 K7ZCZ Status feedback => resolved
2019-11-09 13:27 K7ZCZ Resolution open => fixed
2019-11-09 13:27 K7ZCZ Note Added: 0009220
2019-11-09 14:03 w2pj Note Added: 0009222
2019-11-09 17:16 WA9PIE Tag Attached: 6.7 defects
2019-11-10 23:15 WA9PIE Fixed in Version =>
2019-11-10 23:35 PD9FER Note Added: 0009243
2019-11-11 05:01 WA9PIE Note Added: 0009251
2019-11-11 05:22 g3ucq Note Added: 0009252
2019-11-11 06:03 WA9PIE Note Added: 0009256
2019-11-11 06:46 PD9FER Note Added: 0009257
2019-11-11 09:57 g3ucq Note Added: 0009258
2019-11-11 09:58 g3ucq Note Added: 0009259
2019-11-11 15:20 WA9PIE Note Added: 0009263
2019-11-11 18:50 w2pj Note Added: 0009268
2019-11-11 20:54 WA9PIE Note Added: 0009269
2019-11-11 22:20 w2pj File Added: System Restore.PNG
2019-11-11 22:20 w2pj Note Added: 0009270
2019-11-12 02:49 PD9FER Note Added: 0009271
2019-11-12 02:52 PD9FER File Added: HRDLogbookCallsignEnable.jpg
2019-11-12 02:52 PD9FER File Added: HRDLogbookCallsignLookup.jpg
2019-11-12 02:52 PD9FER File Added: HRDLogbookCallsignLookup.txt
2019-11-12 02:52 PD9FER Note Added: 0009272
2019-11-12 03:38 g3ucq Note Added: 0009273
2019-11-13 05:39 g3ypp Note Added: 0009293
2019-11-14 03:01 WA9PIE Assigned To g3ucq => WA9PIE
2019-11-16 16:44 WA9PIE Status resolved => closed
2019-11-16 16:44 WA9PIE Testing Not Started => Beta Successful
2019-11-16 16:44 WA9PIE Note Added: 0009332
2020-02-04 23:41 WA9PIE Fixed in Version =>
2020-02-04 23:48 WA9PIE Project 3 - Current Dev List => Ham Radio Deluxe