I just got another laptop and have installed Winlink Express, VARA HF (4.6.3) and VARAC (50.2). I entered my VARA HF license key and saw the message that said it was registered. Winlink Express uses VARA HF and it operates at full speed. When I use VARAC and hit the Tune button, it complains that a registration key for VARA is required.

Just updated to 4.1.6. When Clicking Settings -> Canned Messages and trying to insert or delete text in any of the canned messages, after the first key press, the cursor moves to the end of the text already there. For example: Editing the Welcome Message, if it currently reads: Hello, you've reached Joe and you want to edit it to read: Hello, this is Joe When you click to place the insertion point after the word "reached" and press the backspace key, it will delete the last "d" and then jump to end of the text (after "Joe") and start deleting text from there. This means you can only edit the text in the canned messages by deleting everything from the end of the text, back to where you want to start inserting text.

VarAC already handles rig control via CAT, and does it well. What it doesn't do, at least for the radios I have, is update the frequency shown when it's changed from the radio. In other words, you have the frequency list at the top right corner. Selecting a frequency from the list changes the frequency on the radio, but changing the frequency on the radio does not change the frequency shown in VarAC. An example where this might be of help: If I use the VarAC list to select 14.105.00 and accidentally nudge the tuning dial on the radio to 14.105.35, I won't know why I can't connect. If VarAC displayed the radio's VFO frequency, as read by using a CAT command, I might see what the problem is. The rig's VFO frequency displayed in VarAC would serve as a way of confirming that everything is working properly. Another idea, if the first is implemented: If the frequency shown in the VarAC frequency list does not match the radio's current frequency, the radio frequency display could turn red to indicate a mismatch between the radio's actual VFO frequency and the frequency selected in VarAC.

I just updated from v3.5 to v3.6.5 by copying the VARAC.EXE file to the C:\VARAC folder. I went to the settings page Rig Control and VARA Configurations, did not make any changes, and then clicked SAVE & EXIT. I got the following error pop-up: Incoming file misconfiguration VarAC does not have WRITE permission to the ADIF directory C:/VARAC (The forum is not letting me upload images to the group)

I've set the volume on my desktop computer to a level that works well for playing YouTube videos, editing my own videos etc. When VarAC sends an alert, I find the volume level to be way too loud. There's currently no way to lower the volume of the VarAC alerts independently of the system audio level. I would like to see an alert volume slider in the VarAC settings screen which would allow the user to reduce the volume of the alerts from 0 - 100% of the current system volume. A setting of 50%, for example, would mean that the alerts are played at half the volume of regular system sounds and media.

Not sure if this is a bug report or a feature request... When involved in a QSO, it's possible for one station to send a QSYU/QSYD command, while the other person sends an identical (or opposite) QSY command almost simultaneously. Both stations are prompted to QSY with a pop-up dialog box. One station hits yes , thinking he's confirming his own QSY, and a QSY is performed at that station. However, he was really confirming the QSY request from the other station! He then gets the the prompt for his own QSY request, and maybe it takes its input from the characters he's typing into the New Message box and it does ANOTHER QSY! Now he has moved twice and the person he is communicating with is left one QSY behind. The two stations will not link up again as they are transmitting 750Hz apart. The problem can also happen when one station sends a QSYU and the other station sends a QSYD. If the pop-up dialog box is cleared due to the operator typing a message and hitting enter (to send his message --- but the dialog box takes that Enter key as a "Yes, go ahead and QSY") then then the stations could end up 1500Hz away from each other. The operator typing may not even see the dialog box because it shows up just as he's hitting Enter to send his message. Maybe this could be avoided by having a QSY timer. For example if either station receives a QSY request within 30 seconds of a previous request, that request is either ignored (not great) or there's a pop-up which says it could be a duplicate request. There should be no keyboard shortcut or default action on this window, otherwise regular typing could be taken as the response and the problem continues. This would force the user to read the prompt and manually click on it.

I was in a QSO today with a new user of VarAC. I was telling him about the QSYU and QSYD buttons and told him "Do not type a message with 'QSY U' or 'QSY D' (no spaces) in it." He sent the reply, "Does hitting the QSYU/QSYD buttons automatically send a QSY request?" Well, you can guess what happened! As soon as VarAC parsed the message, it saw "QSYU" and initiated a QSY up 750 Hz. While we were both using version 3.4, we were unable to re-sync our operating frequency so had to abort the QSO, go back to the calling frequency and call each other again! Then we deliberately QSY'd away from the calling frequency (which worked). Wouldn't it be better if the Gestures had to be enclosed in an "escape" character? Tags already are, like "<NAME:xxx>", "<QTH:xxx>" and "<LOC:xxx>". Why not the Gestures? I'm sure people are tired of hearing three dings every time I tell them about the DISCO I went to last week! LOL. Enclosing the Gestures in an escape character, such as "<QSYU>" or "[QSYD]" or "[HIHI]" would avoid accidentally sending regular text that is processed as a command.

I'm loving VARAC version 3.4... with one exception, the QSY pop-up! Actually, I like the QSY feature very much, but the pop-up appears with Yes already highlighted and ready for input. The problem is that if I'm typing something into the outgoing message buffer when the pop-up appears, the dialog box takes my typing as its input. The dialog box can then disappear and I won't know what it did and it may have done something I didn't want to do - like QSY down directly onto another nearby station instead of allowing me to not QSY down, but QSY Up instead. I think it would be better if the dialog box for confirming a QSY request were somehow inactive so that the user would have to actively click on it to accept or deny the request. That way the user could continue typing his/her current outgoing message, send it, and then QSY. Anyone agree? Disagree?