Feature request: improve hardware button sampling and reading in both target and simulator

[unsigned_char_array]

Right now hardware buttons work the following way:

The TouchGFX engine checks if the button value matches the trigger set up in the designer in the generated method of the screen view base handleKeyEvent().

In target hardware the method Sample() of your button controller (base class touchgfx::ButtonController) is called by TouchGFX engine. 

In simulator the vent SDL_TEXTINPUT is used. If you hold a key the event will happen in rising edge of the key press  and then re-occur periodically if you hold it down, because the keyboard event repeats.
Using SDL_KEYUP would make more sense as touch button widgets also produce a pressed event on falling edge of button press (button release).

You cannot read the values the engine gets from the target hardware or simulator in the model directly. You would have to send them from view to presenter to model and do that for each screen. This is tedious.
Alternatively you can retrieve the HAL instance and sample again:

uint8_t key = 0;
auto hal = HAL::getInstance();	
hal->getButtonController()->sample(key);

The problem is that this won't get identical values. It samples the buttons again. The buttons could have changed in the mean time. It also breaks the flow where touch and button events are sampled at specific points in time. It also doesn't work in simulator as the buttoncontroller in the simulator is null.

My suggestion is the following:

1. Make a setting in TouchGFX designer to select if you want to use hardware button press or release event. And use the matching SDL_KEYDOWN or SDL_KEYUP in simulator as a trigger
2. use ButtonController also for simulator. 
3. Add methods to the touchgfx::ButtonController class: read() which would read the sampled values without modifying them and readRising() and readFalling to read the value that was changed between calls of Sample() 

Additionally I personally use only digits for hardware button values e.g. 0x31 ('1'). because those can be generated by both target hardware and simulator. You cannot generate ASCII character 0x01 in simulator. It confused me those characters are even an option in the designer.

Last but not least it would be nice if hardware buttons could trigger button presses of button widgets. Right now we have a project where we do this by generating fake touch events to trick the TouchGFX engine. These projects have physical start and stop buttons that are used if the screen is capacitive touch so that operators can use gloves. This is tedious, but the advantage is that both hardware and widget button presses result in the button animation and it will trigger identical behavior using the same event handler. Other projects use resistive touch so that a physical button is not needed.

[LouisB]

Hello @unsigned_char_array,

Thank you for your suggestions, right now we dont have plan for the simulator but this will be brought to the team.

I dont get your point regarding sampling what is the issue with handleKeyEvent(), do you have a concrete use case ?

* For executing action from the button, you can just use executeAction() on your button. AbstractButton | TouchGFX Documentation.

* Regarding the ASCII char numbers, they are used to simulate hardware buttons with the keyboard keys (65 is capital key A, 97 is key a, ...)  You said these cant be generated on your side, what error do you get ?

BR,

[unsigned_char_array]

---

@LouisB wrote:

I dont get your point regarding sampling what is the issue with handleKeyEvent(), do you have a concrete use case ?

---

You either have to create events for each buttons in TouchGFX designer or you overload the virtual method in each screen:

void Screen1View::handleKeyEvent(uint8_t key)
{
    // custom key handling here
    
    // call base class method to handle generated triggers from Designer:
    Screen1ViewBase::handleKeyEvent(key);
}

and then send them from view->presenter->model for each screen.
I want to know in model which button is pressed. One use case is hardware test screen.
In that case I need to do view->presenter->model->presenter->view.

---

@LouisB wrote:

* Regarding the ASCII char numbers, they are used to simulate hardware buttons with the keyboard keys (65 is capital key A, 97 is key a, ...)  You said these cant be generated on your side, what error do you get ?

• Key 65(dec)/0x41 is 'A'. (works but requires shift or caps lock)
• Key 97(dec)/0x61 is 'a'. (works)
• Key 49(dec)/0x31 is '1' (works)
• Key 0(dec)/0x00 is not a printable ascii character and cannot be generated by a keyboard, it is also a NULL character and is used when no key is pressed, so better to avoid it
• Key 1(dec)/0x01 is not a printable ascii character and cannot be generated by a keyboard

My issue is that you can select these non-printable ascii characters and they are also the first ones suggested.

I modified my SDL file so it uses the edge of the keyboard buttons. It was easy to change:

  case SDL_TEXTINPUT:
      //if (strlen(event.text.text) == 1)
      //{
      //    keyPressed = (uint8_t)(event.text.text[0]);
      //}
      break;
  case SDL_KEYUP:
      if (event.key.keysym.sym == SDLK_F1)
      {
      ...
      else
      {
          if (event.key.keysym.sym >= SDLK_1 && event.key.keysym.sym <= SDLK_9)
          {
              keyPressed = (uint8_t)('1' + (event.key.keysym.sym - SDLK_1));
          }                           
      }
      break;

[LouisB]

Hello @unsigned_char_array,

You can use this other function, when using the simulator :

uint8_t key;
hal->sampleKey(key); // This can only be used in the simulator
auto hal = HAL::getInstance();
if (key == 'b')
{
    button1.executeAction();
}

You have to keep in mind that, the key value is a value from 0 - 255 intended for the target. If the character selected cant be generate by the keyboard, you can use the function above.

BR,

[unsigned_char_array]

bool HALSDL2::sampleKey(uint8_t& key)
{
    if (keyPressed)
    {
        key = keyPressed;
        keyPressed = 0;
        return true;
    }
    return false;
}

As you can see sampleKey() clears key keyPressed. So if called in Model it will always return false. Key argument also has to be explicitly initialized to 0, because if sampleKey is false the value won't be set.