LC Indy 9
MacBook Pro
Create a new stack and place a browser widget on the first card. Get a beep whenever a key is pressed on the keyboard. onKeyPress in main stack is not triggered except for escape key. No keys are passed to Javascript in the browser except backspace.
Borowser Widget Blocking Keyboard
Moderator: Klaus
Re: Borowser Widget Blocking Keyboard
Not sure if that is a bug?
If you add a text field to the stack the issue disappears, even if the field doesn't have the focus.
I suspect the browser object does not respond to keystrokes directly and you need to add something that will.
I think possibly people show/hide the browser in circumstances where this will be an issue.
Then again i have no real experience with this, so others may chime in!
Stam
If you add a text field to the stack the issue disappears, even if the field doesn't have the focus.
I suspect the browser object does not respond to keystrokes directly and you need to add something that will.
I think possibly people show/hide the browser in circumstances where this will be an issue.
Then again i have no real experience with this, so others may chime in!
Stam
Re: Borowser Widget Blocking Keyboard
I suspected it was something dopey like that- just needed to hear it from someone.
You'd expect that keyboard events would go to the stack before the widget, especially if the widget is going to eat all of them.
You'd expect that keyboard events would go to the stack before the widget, especially if the widget is going to eat all of them.
Re: Borowser Widget Blocking Keyboard
Also, just tried adding an input field and apparently it does require focus for the beeping to stop. Back to the drawing board...
Re: Borowser Widget Blocking Keyboard
What is "onKeyPress"?Also, just tried adding an input field and apparently it does require focus for the beeping to stop.
Anyway, do you mean that you have, say, a mouseUp handler in the card or stack script that beeps if you click somewhere on the card, but does not beep if you click on the widget?
I have never used a widget, but I am not surprised that it is trapping common events. For example, if you invoke the beeps with any sort of "mouse-like" message, like "mouseUp", mouseDown" or "mouseStillDown", clicking on the widget seems to trap them. But if you use "rawKeyDown", for example, the message passes through the widget just fine.
I cannot imagine how adding another control to the card could possibly have an effect of any kind on the message path through the widget itself.
Craig
Re: Borowser Widget Blocking Keyboard
I don't see that problem, I have a browser widget in use on a card which loads a web form from the internet. I can type into the form and submit it.
In the widget's property inspector, is "allowUserInteraction" selected?
In the widget's property inspector, is "allowUserInteraction" selected?
Jacqueline Landman Gay | jacque at hyperactivesw dot com
HyperActive Software | http://www.hyperactivesw.com
HyperActive Software | http://www.hyperactivesw.com
Re: Borowser Widget Blocking Keyboard
In this instance I am not using any HTML controls. Instead, I am drawing to the screen with a Javascript library that displays WebGL.
To reproduce, start Livecode, create a new stack with a browser instance in it, run the stack and give it focus, then type away and enjoy the beeping. Mouse events do not cause any beeping.
Also, put a rawKeyDown handler anywhere you like- no keyboard events will reach it while the browser widget has focus.
And yes, ‘allowUserInteraction’ is on.
To reproduce, start Livecode, create a new stack with a browser instance in it, run the stack and give it focus, then type away and enjoy the beeping. Mouse events do not cause any beeping.
Also, put a rawKeyDown handler anywhere you like- no keyboard events will reach it while the browser widget has focus.
And yes, ‘allowUserInteraction’ is on.