|
Workaround
I tried various methods of getting round this, I tested a very large edit box at an opacity of 1% that can be set over the whole widget, this would have allowed a CTRL key to be captured. Unfortunately, mouse-through does not seem to work with edit boxes so all onMouse events for all other objects sitting below are negated when a large edit box is positioned directly above them.
There is however a isKeyDown() function that checks for a keydown event that actually works...
To capture a keydown event the isKeyDown() function has to be inserted into a place in your code, typically an event function. For example, during a onMouseDown event this code might be inserted:
Code:
if (isKeyDown(40)) {
// right volume up
if (debugFlg === 1) {print("%KON-I-INFO, pressing down the cursor UP key ");};
sliderSet.left = sliderSet.left - 10 ;
limitSliderSet();
}
However, this would only capture the keydown event when the mousekey was pressed simultaneously. So, we have to be inventive to ensure that the only trigger for the keypress is the keypress itself and as a result it needs to be inserted into something keyboard/mouse-neutral that occurs all the time... there aren't many of those - except for a timer event!
Create a timer called keyTimer and set the frequency to 50ms, insert the above code into the keytimerOnUpdate function. This will cause the timer to activate the function every 50ms and determine whether a valid keypress has been made. This is the workaround I was looking for, a bit over-complex for a simple key capture but in the absence of a working onKeyDown function it must suffice.
The isKeyDown(keyCode) function uses the standard javascript keyboard scan codes to determine which key is pressed. Find those here: keycode.info/
There is an unexpected side-effect, the key capture occurs all the time and not just when the widget has focus. The isKeyDown function works whether you are typing into a word processor or writing an email, if the widget is running on your dektop you will find the media player reacting seemingly randomly to your email keypresses. To get round this you simply need to turn off the timer when your mouse leaves the widget and then turn the timer back on when the mouse re-enters. In the IDE in design mode, select the WIDGET object and enable an event for both entering and leaving the widget, assigning the following code:
Code:
function widgetOnEnter()
{
keyTimer.enabled=true;
}
function widgetOnLeave()
{
keyTimer.enabled=false;
}
The regular frequency of the timer could be increased to 100ms interval to reduce the cpu overhead of such a frequently run timer. Unfortunately, the result would be that keypresses would seem 'halting' and jerky in their capture. The 50ms interval makes for smooth response while a 100ms interval feels unresponsive and 'wrong'. There is a cpu penalty for frequently running such a function and it is only necessary due to incomplete features in the Xwidget engine.
However, we have a workaround for the absence of the onKeyDown event and it means that we can now say that Xwidget does have the ability to capture a keyboard event.
Note that this is a limited workaround as the mouse cursor needs to be hovering over the widget in order for this to work. It should operate when the widget gains focus and only stop capturing keypresses when the widget loses focus.
|
Login
FAQ
Search
