I suspect the QRZ.com lookup is mostly unrelated; neither of those tests make any difference with the function key definitions used above. OTOH waiting for the automatic lookup has made a difference b

OK After the last digit of the received report I have just typed in. In the tramsmit typing area at the start (typing area cleared when message fully sent by keyer). Yes. 73 Bill G4WJS.

I took that to mean "where is the input focus" rather than "where is the mouse cursor". I hope I have that right. 73 Bill G4WJS.

Sorry for the delay getting back to you Dave. Using the function key definitions above; the first letter I type after the F10 function key definition has played out is ignored, if I type a second and

<snip> That explaination is consistent with my tests - using a different function key gives non-defective behaviour. Sounds like this might be a tricky issue to get around :( I'll rearrange my functio

Hi, I've recently been using DXK in 2-pane format. On the Check Progess tab there is a spurious text input (Text1) located about 100px below the "Run Script" and "Recompute" buttons. Also clicking the

Hi again, Forgot to mention than in all cases (I believe) resizing the Window fixes the broken layouts. 73 Bill G4WJS.

Yes the issues are reproduceable after a shutdown and restart of Windows. Some details that might help. Windows XP SP3. 1280x800 display in 32bit colour mode. Auto hide on Windows task bar. The issues

WinWarbler behaves similarly. I find this quite disruptive when I mis-copy a callsign and only realize after I have entrered some other details. The problem is that the only way to log a QSO correctly

That isn't what I was proposing. There is no reason why the implementation of DXK:capture and WW cannot remember which fields have been typed into. I wasn't suggesting anything arbitary. Please read w

Thanks for the suggestion Ian, I have tried that, but it is no better than wiping the QSO and starting again. In fact it is worse because if I forget to take note of any fields I have changed I lose t

I can't disagree with that sentiment but I also feel quite strongly that the following scenarios are unhelpful. 1) Use the option Iain suggested and run the risk of losing QSO data typed in just by ch

<snip> That's fine if you consider the CB lookup as a source of post QSO info like QSL routing etc. but I suspect most operators who have the auto CB lookup enabled do so because it allows them to ope

You might need a screen driver that supports panning the virtual display (I've no idea if the EeePC supports that) so you can set a higher resolution than the native resolution. Not optimal, but at le

I understand the issue, if time passes before you detect the problem then things get complicated. The other poster that suggested just letting DropBox do its thing to get the file back is best IMHO af

<...snip...> I have also hit a similar problem when helping another op to import his log from WinLog32. That program seems to set "QSL_Sent" to 'N' by default for QSOs that haven't been used to send a

Hi, this may be a "feature" of my printer rather than a problem. I have my printer set to manual feed for all DXK QSL printing. When I print labels with more than one sheets worth in the QSL queue; th

Hi again, I appear to have solved this one. I switched from the HP Postscript driver to the PCL driver for the printer (HP LaserJet 1200) and it now waits after each page when manual feed is selected.

IMHO there is a flaw with that process. The way workspaces work is not consistent with the way DX Labs Suite works with a single workspace. If you switch workspaces without updating first any changed

I can see the point in this request. I would like to add a couple of points. Firstly I can see a problem: Sometimes a stn gets respotted quite quickly with a small frequency correction which is more a