开云体育

Come on! For what we are paying you, you should be right on top of all this :-) Just kidding of course, I am amazed that you are able to respond as fast as you do to these things. ---- 73, Rich -

This is easily implemented, and the "crash while iconified" defect is easily repaired -- but work committments will push this out a few days. 73, Dave, AA6YQ

It would be nice after clicking "clear" in the capture window if the keyboard focus would go to the callsign entry window as it does after clicking "log". I often find myself trying to type a new

Closing DXKeeper while it is minimized on the task bar by right clicking on the task bar icon and selecting close, produces the following error: "Run-time error '384' A form can't be moved or sized

You have it cooking now Dave. 73, Rich - w3ZJ

This release - corrects a defect that prevented the import operation from properly crediting QSOs that were worked but not confirmed - corrects a defect that caused PSK QSOs to not be included

I think the answer that would best satisfy the most people (and certainly me), is place the first word in the name field and every thing else in the comment field. It won't be 100% but it will

If there's no standard for how the information is jammed together, then it will be difficult to satisfy everyone. Sounds like "Import from Logger" should mean "place the contents of the name field

Yes, of course I saw that too and Logger is a bit flaky on that score because it doesn't have separate fields for name and QTH and the exports the comment field with the <NAME> tag. I could see what

The progress problem is a defect that was easily fixed; I'll send you a progress report file so youc an verify that this was the only problem. I noticed a lot of "truncated name" messages. With the

Dave, The import went fine, except for the program error that occurs at QSO #3757. I found that all I have to do to recover from that is to close and reopen DXKeeper, then start the import again.

That's a pretty good clue, Rich -- it implies that the import operation is not properly handling worked-but-not-confirmed QSOs. I've imported my 13K QSOs (from the first-generation DXLab, which began

Dave, I am still having a problem with the Progress Table not showing correct results for imported log entries. I did a little more research and found that the only entries that were appearing in the

DXKeeper 1.1.6 corrects a defect that prevents addition of the first QSO to a log via the Capture Window. This release also includes further improvements to the online help. If you've already

Along with the DXCC database support described below, this release also includes updated online help, which is accessible via http://www.qsl.net/dxkeeper/Help/index.htm . If you've installed

I should have a new version of DXKeeper ready tonite -- it doesn't use DXView during imports, and thus should eliminate the performance problem. Then we can determine whether there is an additional

Yes, multiple databases are to be avoided. I started with the notion of one DXCC database managed by DXView, with other applications invoking DXView for callsign lookups, etc. But its unacceptable

OK, a bunch of stuff here. First I have succeeded in getting the import to work with DXView. Here is what I did: 1) Closed all applications and closed my dial up connection. 2) Disabled Norton

Wow, that is a bit complex but it sounds like you have a good handle on it. The problem of keeping two copies of a database in sync without requiring data to be entered in two places is always a bit

To ensure its ability to perform callsign lookups, DXKeeper will from now on include a copy of the DXCC database previously only packaged with DXView. During startup, DXKeeper will determine whether