search

google / radioreceiver

An application to listen to broadcast stereo FM and AM radio from your Chrome browser or your ChromeBook computer using a $15 USB digital TV tuner.
https://chrome.google.com/webstore/detail/radio-receiver/miieomcelenidlleokajkghmifldohpo
Apache License 2.0
394 stars 80 forks source link

f key to focus on frequency display #5

Closed GeoNomad closed 8 years ago

GeoNomad commented 9 years ago

Currently f invokes showFrequencyEditor() which is undefined.

I thought it would be easy to fix with frequencyDisplay.click() but for some reason that causes a crash.

Neither frequencyDisplay.focus() or frequencyInput.focus() did anything.

Sorry to be a bit of a newbie with this stuff. But it is a good learning experience...

I'd love to have an explanation.

Thanks.

jtarrio commented 9 years ago

Yes, that function used to exist, but as I added more clickable numeric fields I extracted that functionality into attachDisplayInputEvents() and forgot about the keyboard shortcut. I'll see if I can fix that soon.

GeoNomad commented 9 years ago

I have fixed it in my fork. Not sure what caused a crash earlier - but it seems to have been unrelated. I did it in a rather ham fisted way. Perhaps you can suggest a more elegant method.

I have noticed that if you change modes too quickly (this happens with my new preset up/down functions when the user hits the PgUP or PgDn key multiple times quickly), it looks like either some function is called before it has completed, or new instances of the decoder are being created that interfere with each other - resulting in odd behavior or non-responsiveness.

Is there a flag I can use for when the decoder is ready to accept these kinds of changes? I am assuming that I could check to see if play() has been called since the last change, but maybe you have a better way that I haven't noticed.

I love this program and have learned a lot from your programming style, being pretty incompetent in javascript/html5. You have done a great job!

Thanks, Peter

jtarrio commented 9 years ago

Perhaps the change event is fired in presetsBox already when you set the selected item, thus calling selectPreset(), and then you call the selectPreset() function again?

GeoNomad commented 9 years ago

Well, yes, I am calling selectPreset() again, but it is intentional. Since it is done with a keypress, it is easy to call it multiple times with no wait between. Just tap the key.

That is what I want to avoid (with a view to automated scanning of presets).

How best to know that the system is ready to call selectPreset() again after a previous call?

I can easily block the second call if I know when the some aspect of the system is busy and can't take another one yet, But, how best to know that?

jtarrio commented 8 years ago

Published a version where 'f' now focuses on the frequency edit box.