#22 ✓resolved
JohnJames

fine adjustments of freq with left and right arrows

Reported by JohnJames | April 25th, 2010 @ 04:55 AM

When needing to clarify a signal (especially on CW) it would be nice to adjust the receive frequency by use of the left and right arrows. Possibly +-1 Hz normally and if option key is down adjust +- 10 Hz.

Scroll wheel is a little too gross.

Comments and changes to this ticket

  • JohnJames

    JohnJames April 25th, 2010 @ 04:56 AM

    Tried to add:
    (void)keyDown:(NSEvent *)theEvent{...}

    in WaterFall view but never called???

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) April 25th, 2010 @ 05:03 AM

    It's probably because the WaterfallView doesn't have the focus, and
    the key press is not sent to it. I believe that the First Responder
    needs to be set to the piece that you want to respond to the keyDown
    event.

  • JohnJames

    JohnJames April 25th, 2010 @ 05:13 AM

    Is this a coding fix or a user behavior fix? I tried clicking on the Waterfall before I tried the <- -> keys. It did not help. It finds the mouseUp fine. But when I hit the left and right it rings the bell, (which sounds like the Focus error you mention).

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) April 25th, 2010 @ 05:19 AM

    This is a coding change. XTWaterfallView is not enabled to take
    focus. I have to think on it and figure out which UI component really
    should be the First Responder and react to the keyPress event. It
    shouldn't be either XTWaterfallView nor XTPanadapterView because it
    should respond whichever happens to be there. Probably it should be
    the view of the entire main window that handles the event, this way
    whenever the window has focus, you'll grab the keyPress event. The
    way to do this is probably going to be to delegate the event to
    somewhere else, maybe the main application object.

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) April 25th, 2010 @ 05:36 AM

    Also, if there is going to be a modifier key for 1 or 10 Hz
    increments, it should not be option. I'm trying to reserve option for
    "subreceiver" functions. So, if the arrow keys are implemented,
    option-arrow should move the subreceiver frequency. Possibly shift is
    the modifier key to use for the increment adjustments.

  • JohnJames

    JohnJames April 25th, 2010 @ 10:39 AM

    And maybe shift-option arrow could adjust the subreceiver.

  • mcdermj (at xenotropic)
  • JohnJames

    JohnJames April 26th, 2010 @ 04:50 AM

    Tried (a quick and dirty) to do this with buttons on MacHPSDR window. (linked in <- and -> arrows-keys to buttons.)

    just did the following:
    transceiver.frequency += 10;

    This changes the frequency in the main Receiver window but does nothing for the real freq as heard nor as seen in the Panadaptor. Is there an update method/ Notification I should do for the PanAdaptor?

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) April 26th, 2010 @ 05:05 AM

    The fact that you're not hearing an audio change means that you're not calling [TransceiverController setFrequency:(int)theFrequency]. The text frequency display in the window is bound with cocoa bindings to the TransceiverController object in the NIB. The panadapter layer doesn't require any notification. It registers for notification on the transceiverController object (see the awakeFromNib method on XTPanAdapterView), and will automatically change if the frequency changes in TransceiverController.

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) April 26th, 2010 @ 05:43 AM

    (from [147]) Added rudimentary support for arrow key changing on the main window. This does not yet detect which key has changed, or implement modifier keys, but it is a start to the architecture. [#22]

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) June 14th, 2010 @ 04:41 PM

    (from [149]) Added the arrow key code from John James [#22]

  • mcdermj (at xenotropic)

    mcdermj (at xenotropic) March 3rd, 2011 @ 09:55 PM

    • State changed from “new” to “resolved”
    • Milestone order changed from “0” to “0”

    Marking this one as resolved. I believe the code implemented is working fine.

Please Sign in or create a free account to add a new ticket.

With your very own profile, you can contribute to projects, track your activity, watch tickets, receive and update tickets through your email and much more.

New-ticket Create new ticket

Create your profile

Help contribute to this project by taking a few moments to create your personal profile. Create your profile ยป

An open source software project implementing an amateur radio receiver for the OpenHPSDR hardware.

Shared Ticket Bins

People watching this ticket

Referenced by

Pages