> For example, this is the
> opposite of the way TRLog is designed, with function keys that change
> definition as the program changes its "mode" on its own, depending on what
> it "thinks" you're doing.
I agree with you on this. It is one of the BIG reasons I refuse to use
TR, and refuse all invitations to Multi's that use TR. Let's leave the
BPK basically as is and stay consistent.
> However, I would offer that pressing the
> BPK, or the return key for that matter, prior to receiving confirmation of
> your exchange is bad practice.
No. It is an honest mistake if I meant to hit the INS key to SEND
the exchange. (And I do wait until receiving confirmation before
pressing ENTER to post the contact to the log.) Most keyboarding
errors in NA, CT and Writelog (not TR) are easily corrected by
pressing the ESCape key, but this one isn't. In a 2nd radio contact
it screws everything up, and the intention is never to QRZ after an
S&P contact anyway. If the BPK were ignored during 2nd radio
contacts, that would be cool. It is common practice in software
design to lock out functionality that is inappropriate in a narrow
context.
> F1 and F4 now apply to the main radio while making an SO2R QSO, which I think
> gives enough
> capability in this situation.
F1 sends a CQ, and F4 sends my call, which is fine. But when
people are already calling I NEED to send didahdididit on the main
radio and there is currently no way to do this. If not the
BPK, then somewhere else. Even an Alt-something key would be
fine, since I would re-map it anyway(probably to one of the
punctuation keys near ENTER).
Roy -- AD5Q
--
Submissions: na-user@contesting.com
Administrative requests: na-user-REQUEST@contesting.com
WWW: http://datom.contesting.com/
Questions: owner-na-user@contesting.com
|