579 views
in GUI Development by
Hello,

       I have a KeyHandler that is has the filter set to "Core::KeyCode.AnyKey". In the keypress event I'm checking to see if (KeyCode == Core::KeyCode.Enter). But, when I press the enter key this condition is not satisfied. Also, is it possible to do a check like this: if (KeyCode == Core::KeyCode.AlphaOrDigitKeys)? I tried it but no luck..

Thank you!

1 Answer

+1 vote
by
 
Best answer

Hi,

let me start with your first question. In fact specifying the filter condition AnyKey will not provide the key code Enter as you have expected. Instead the code Core::KeyCode.Ok is reported when you press the ENTER key. Why is it so?

Embedded Wizard technology was designed years ago originally for TV sets. As you might know there is no ENTER key on a typical TV set remote control. Instead there is an OK key. In order to allow the developer to test how the TV set application will behave when particular remote control key is pressed we had thus to convert the PC keyboard keys in corresponding remote control keys. In particular pressing the key ENTER on the PC keyboard is reported as Core::KeyCode.Ok. See the Prototyper window chapter for a screenshot demonstrating this mapping.

Later we enhanced the keyboard functionality also to support application running on PC or other devices not TV sets. With this step we support many typical PC keyboard codes like ENTER, CTRL+C, etc. However, this approach is not compatible with the application running for 'old' TV sets. When the user presses the ENTER key, what should happen? Should the event be delivered as Core::KeyCode.Enter or Core::KeyCode.Ok code?

Our approach was to remain as far as good compatible with the codes used by older applications and allow new applications to work with new codes. This is achieved by sending the keyboard events twice. In particular: when the user presses the key ENTER we send first the code Core::KeyCode.Ok and try to find a handler for this code. If there is no handler found, we send another event Core::KeyCode.Enter. In this manner older TV set and newer PC like application can be developed and tested with Embedded Wizard.

Well, specifying the filter condition Core::KeyCode.AnyCode causes your key handler to respond to the first event with the code Core::KeyCode.Ok. Consequently, the code Core::KeyCode.Enter is not delivered anymore. This special compatibility mode is implemented primarily in the Prototyping window so the developer is able to test GUI applications in all cases (for old TV set or even other device). This Prototyper behavior can't be changed.

In turn, in the target device (in your final product) you have the full control of how the keyboard codes are mapped to the corresponding Core::KeyCode values. This, however, will not help you a lot since you want your application to run also in Prototyper. Therefore the best would be one of the following approaches:

Approach 1: Don't use Core::KeyCode.AnyCode

Instead use several Key Press Handler objects, every configured with an individual code as filter condition. For example, you can add a handler and configure it with the filter condition Core::KeyCode.Enter. As described above the Prototyper will provide the appliction with the code Core::KeyCode.Enter if there is no other handler interesting in the Core::KeyCode.Ok.

Approach 2: Adapt the if-condition in your slot method.

Instead of:

if ( KeyHandler.Code == Core::KeyCode.Enter )
  ...

use following condition, which is true for both the 'old' Ok and the new Enter code:

if (( KeyHandler.Code == Core::KeyCode.Enter ) ||
    ( KeyHandler.Code == Core::KeyCode.Ok ))
  ...

Now let me focus on your second question. You would like to test whether the user has pressed an alpha or digit key. With the filter condition Core::KeyCode.AlphaOrDigitKeys you limit the affected handler to be able to react to keyboard events caused by alpha or digit keys. So far it is ok. The if-condition, as you tried to apply will however not work. Why?

When the user presses a key e.g. 8 (eight), the key handler reacts to this event since it is configured with the filter condition Core::KeyCode.AlphaOrDigitKeys. Thereupon the handler signals your slot method connected to the handler's OnPress property. While this slot method is executed you can evaluate diverse variables of the handler. These variables store the actual code of the pressed key. In this case the code for the key 8

The variabe don't store the value of the filter condition. Thus the following condition will not work:

if ( KeyHandler.Code ==  Core::KeyCode.AlphaOrDigitKeys )
  ...

Instead you have to test precisely whether the variable contains the code of a particular key. You can also test whether the value of the variable lies within a given range. For this purpose you can use the variable CharCode, which contains the UNICODE character of the affected key. In this manner you can test whether the code belongs to a group of codes (e.g. alpha or digit):

if ( KeyHandler.Code == Core::KeyCode.Key8 )
  trace "The user has pressed 8";

if (( KeyHandler.CharCode >= '0' ) && ( KeyHandler.CharCode <= '9' ))
  trace "The user has pressed a digit key";

if (( KeyHandler.CharCode >= 'a' ) && ( KeyHandler.CharCode <= 'z' ))
  trace "The user has pressed a lower letter key";

Hope it helps you further.

Best regards

Paul Banach

by

Hi,

I figured out a very similar problem, and using

switch(KeyHandler.Code) {
  case Core::KeyCode.Ok: {onPressOk(); return; }
  case Core::KeyCode.Right: {onPressOk(); return;}

Both keys work fine using the prototype within EmWiz.

Then I built the code via PlatformPackage "Tara.WebGL.RGBA8888", and started the generated file EmWiApp.html. "KeyCode.Right" works fine, but "KeyCode.Ok" doesn't work at all - also replacing by "KeyCode.Enter" didn't work ( I opened the *.html in Firefox and Internet Explorer, the result was the same).

The generated "*.js"-files are generated very compact and hard to read - so it's not so easy finding the issue there.

Do you have any proposals get "ENTER" working under the generated *.html / Javascript?

Thanks.

Ralf

by

Hi Ralf,

thank you for this post. You have detected a bug. Due to an error in the obfuscation routine various key-code identifiers used in the generated JavaScript code do not match the corresponding identifiers in the Runtime Environment library emwi_compr_0_9X.js. This leads to your described problem.

If you are using the professional edition of Embedded Wizard with an active license for WebGL Platform Package, the unique workaround is to disable the obfuscation. However, with this workaround please remind, that disabling the obfuscation will simplify the evaluation of the generated code by third persons.

If you are using the evaluation (free) edition of Embedded Wizard or you have no license activation for the WebGL PP (you are for example evaluating the WebGL Platform Package), there is unfortunately no workaround for it.

Actually we are in process of preparation of a new version 8.30. With this version, the bug will be fixed. The release of the new version, however, still takes few weeks. I have to discuss with my team, whether we can find a way to fix the problem in the actual version 8.20.

Are you using the version 8.20?

Best regards

Paul Banach

 

Ask Embedded Wizard

Welcome to the question and answer site for Embedded Wizard users and UI developers.

Ask your question and receive answers from the Embedded Wizard support team or from other members of the community!

Embedded Wizard Website | Privacy Policy | Imprint

...