In the name of all that is holy, why does Xojo automatically play a system “beep” any time a key press is received by a window, unless the window has a KeyDown event handler that returns “true”??
This seems to mean that in any window that doesn’t do anything with key presses, I need to create a KeyDown handler and put “return true” in it, just to prevent a lot of annoying and pointless beeping. And of course, even in windows that do handle key presses, I still have to throw in lots of “return trues” that serve no other purpose but to prevent beeps. This is a terrible “feature”!
No version of RB that I ever worked with prior to upgrading to Xojo had this issue…
nor does the current version have this issue. Xojo will sound a system beep when the window or control with the input focus receives a keystroke that it doesn’t know how to deal with. Place a textField or a textArea on a window, run the program and begin typing. No system beep when you enter text into either field. Something in your code has removed the focus from where you think it is, or is preventing the entry of some certain characters (do you have a mask on any of the fields?). By the multiple insertion of Return True’s you are attempting to band aid the problem which will continue to plague you unless you find the source of the problem. Happy hunting.
If you’d like to post some of your code, maybe some of us can point you more directly.
To make it easy for you to program auto-tellers that beep when you enter your PIN?
Seriously - you have another problem. Check your hardware. Check you haven’t got some pizza firmly lodged under ctrl or alt. If on Windows, check for viruses. Check you haven’t ticked “I’m blind or senile” under Accessibility Options. Try another keyboard. Else you have some exotic coding problem.
I’m afraid I have to push back here. This is not about my code, and I really doubt it’s about my hardware or weird settings. And yes–I acknowledge that if there’s a textfield or textarea in the window, that averts the issue (because then the textfield receives the key stroke instead of the window receiving it).
But if there is no text field in the window, and no KeyDown handler that returns true, then there’s a system beep any time the user presses a key. Seriously. Run an empty project that just has a window with no controls or code, and you should see what I’m talking about. Every time you press a key, there’s a beep! Or at least, that’s the behavior that I’m seeing… (And again–only in the Xojo version of my app; in the RB 2008 version, this does not happen.)
Add Return True to Window.KeyDown and the beep is gone.
That is correct behavior.
When not implementing the KeyDown event for a window or control, the Xojo framework treats it as if you had implemented the event and returned False, which means: please, Xojo framework, apply the standard behavior. For a window with no control on it that can receive keyboard focus, there is no standard behavior, hence the beep.
FYI… that has NOT always been the case. RB2009 was silent as was RS2012
it was starting with the change to XOJO that it was not quiet anymore
And (guess here), I think it MAY have to due with the fact that prior to XOJO, all the events existed (perhaps empty, but there)… starting with XOJO you had to ADD the desired events…
But I also think that it is NOT Xojo that is causing the beep, but the OS… Since XOJO has no handler for the key it keeps passing it on down the line, then the OS says… Key? what the heck should I do with it?
No, RB applications beeped too when compiled for Cocoa. An empty window in an Objective C application will beep too.
Right. This is an OS thing and has little to do with Xojo. It makes sense, too - you’ve sent a key press to an app that doesn’t know what to do with it.
All I can tell you is I compiled empty app in 2009, 2012 and XOJO using default settings… which perhaps were still Carbon
but as I indicated (and Gavin seems to concur) its an OS thing not an XOJO thing
Huh. Well, even if it’s “correct” behavior, I have to disagree with the opinion that it “makes sense.” Admittedly, this is something that different people will doubtless see differently–but to me, it doesn’t follow from “this window has no use or response for that key press” that the app therefore needs to beep at the user. I mean, it certainly doesn’t behave the same way for mouse clicks, for example!
Also: I already said this, but my experience is the same as Dave S’s; this beeping didn’t happen in any pre-Xojo (RB) version that I ever used (and still doesn’t).
Ah, well. I guess the upshot is that I have to go through all the windows in my apps and throw in a bunch of “return trues”…
The change seems to be CARBON vs COCOA… so again… not XOJO’s “fault”…
Try putting ONE True… .in the APP.KEYDOWN event… I beleive that all unhandled key strokes ultimately end up there
but I do not believe you need to put one on EVERY control.
Aha! Nice thought–I will try that.
For Xojo, not for Firefox: I just checked.
Note: for other’s privacy respect, I have the sound off nearly all the time.
The only exception is (of course) when I play music or when I watch TV. THEN THIS IS HORRIBLE.
PS: everybody here was thinking nothing abainst that when I walked this way two years ago (when I was able to run Xojo, weeks after buying the license upgrade).
Apple and oranges ? AFAIK, no browser ever beeps upon hitting keys…
Eli is right. Beep is the normal behavior for Cocoa, and has been since the RB beta version. In the now outdated Carbon, that was not the case.
That said, adding
Return True in the window keydown suffices to silent it.
I don’t see that event. Is it new?
Can yu share a link to the Apple original documentation, please ?
[quote]Responder Chain for Event Messages
Nearly all event messages apply to a single windows responder chainthe window in which the associated user event occurred. The default responder chain for event messages begins with the view that the NSWindow object first delivers the message to. The default responder chain for a key event message begins with the first responder in a window; the default responder chain for a mouse or tablet event begins with the view on which the user event occurred. From there the event, if not handled, proceeds up the view hierarchy to the NSWindow object representing the window itself. The first responder is typically the selected view object within the window, and its next responder is its containing view (also called its superview), and so on up to the NSWindow object. If an NSWindowController object is managing the window, it becomes the final next responder. You can insert other responders between NSView objects and even above the NSWindow object near the top of the chain. These inserted responders receive both event and action messages. If no object is found to handle the event, the last responder in the chain invokes noResponderFor:, which for a key-down event simply beeps. Event-handling objects (subclasses of NSWindow and NSView) can override this method to perform additional steps as needed.[/quote]