Graphic Button response not working?

[Larelyn]

Apologies if I am missing something obvious, but I am having challenges with graphic button response indicators working in a specific scenario:

I have a display with a field type "graphic button" widget on it. I tab to put focus on the graphic button. Then, when I press my enter key, I expect the response indicator to turn on. It isn't. I can only turn on the graphic button response indicator by mouse clicking it. If I change the field type to "button", pressing enter with focus on the button will turn on the response indicator, as expected.

I'm testing with a bare-bones hello world program, so there isn't much else that should be affecting this behavior. Is this by design? I'm running 5.8.0.

[Scott Klement]

Have you set the Shortcut Key property to "Enter"? Have you disabled the enter key in the screen-level properties?

[Larelyn]

Thanks for responding so quickly, Scott!

I have two buttons on the screen, so I do not want to set the shortcut key property to Enter. This is a test case for me to build a more complex display with multiple buttons the user can tab through. In theory, the user should be able to press Enter to activate the response indicator for any button, depending on which has focus. The field type "button" allows for this behavior. Why would it not work on a graphic button?

Enter is not disabled in the screen level properties.

[Scott Klement]

The browser, of coruse, is what does the "real" work. It controls where the focus is at and what happens when you hit keys, etc. The browser doesn't really know that a "graphic button" is a button. It is an HTML <div> element that has been styled to look like a button to the user. When you click on the div, our JavaScript takes control and handles submitting the form. Likewise, if you set the shortcut key to Enter, our JavaScript code adds code that intercepts the enter key and submits the screen.

But as far as the browser is concerned, it is a <div> element, not really a button.

By contrast the "button" widget is an actual browser <input type="button"> element, using the HTML code for a button. So the browser knows exactly what it is... so it's a "real button" from the browser's perspective. But, the disadvantage to that is that we're limited in how we can control it's appearance.

One workaround that's probably very easy is to put some JavaScript code in the graphic button's "onkeydown" event. Check whether the key pressed was enter, and if so, submit the screen with the pui.click() API. I haven't experimented with this -- but it sounds like it should work. I can try it if you want....

[Larelyn]

This all makes sense - I'm surprised I haven't come across it before. Thanks for explaining it.

I was thinking I would have to use javascript to simulate the action. I'm good with the api's, but thanks for the offer!

[Scott Klement]

Cool, since you're good with the APIs, it should be easy for you. I'm going to post an example, though, just in case someone else has this question and finds this discussion searching the forums.

The basic idea is to define a javascript function that will be called when a key is pushed down on the button. The onkeydown event is run when that happens... it will need to check for key code 13, which is enter.

You can define this function anywhere. One easy thing to do is to define it in the "onload" event for your screen. Provided that you attach it to the browser's "window" object, it will be global, so once the screen loads, you'll be able to call it from anywhere.

onload event:

Code: Select all

window.keyDownHandler = function(event, element) {
  event = event || window.event;
  var key = event.keyCode || event.which;
  if (key == 13) {
    pui.click(element);
    preventEvent(event);
  }
}

The first two lines are for compatibility with old versions of Internet Explorer. Old versions of IE do not pass an event object, but instead use a global variable (i.e. a variable attached to the window object) named event. And the event didn't contain a "keyCode" element, but instead had an element called "which" that did the same thing. In this respect, these old versions of IE didn't follow web standards. Newer versions of IE fixed this, and of course all versions of Firefox, Chrome, Opera, Safari, etc all used the standards.

So after the first two lines, "event" will be the event (whether old IE or not...) and "key" will be the keycode (whether old IE or not.)

Then the task is easy... if the key is 13 (enter) use the pui.click() API to click the element... which will be the graphic button or whatever it is that has this assigned to its onkeydown. preventEvent() prevents the enter key from being propagated up -- so if there's other things (such as a screen-wide keyboard handler) the enter key will not be sent to it.

Now assign this function (without parenthesis) to the onkeydown property of the graphic button, or any other element on the screen (I tested it with gradient buttons, css buttons, regular buttons and of course, graphic buttons). So the property looks like this:

onkeydown event:

Code: Select all

keyDownHandler

It's important to exclude parenthesis here, because that allows the browser to pass the event and element parameters to the function.

For some widget types (including gradient buttons, css buttons, images, etc) you will need to set the "tab index" property to a positive number in order for the tab key to stop at the element. That is what the tab index property does -- when it is positive, the tab key will tab to it, when it is negative, it won't.

That should be it... now either the "response" or "onclick" event for the button will fire when you press enter while focusing on the button.

Hope that is helpful to someone :-)