Welcome, Guest. Please login or register. Did you miss your activation email?

Author Topic: Window Poll Event Mechanics  (Read 1028 times)

0 Members and 1 Guest are viewing this topic.

oz

  • Newbie
  • *
  • Posts: 1
    • View Profile
Window Poll Event Mechanics
« on: February 01, 2025, 03:56:00 am »
I think my error here might be due to my misunderstanding of how RenderWindow pollEvent() works. The problem I am having is with the following code:

void InputHandler::processMenuInputs(const std::optional<sf::Event>& e) {

    if (e->is<sf::Event::Resized>()) {
        // rerender interactables if menu size is changed
        menuManager.queueInteractableLocationUpdate();
        menuManager.queueFrameLocationUpdate();
    }

    if (const auto *textEntered = e->getIf<sf::Event::TextEntered>()) {
        // if text entered worked
        std::cout << "text enter detected\n";
        if (menuManager.textboxInput(textEntered->unicode)) return;
        std::cout << "text entered but not returned\n";
    }
    if (const auto *keyPressed = e->getIf<sf::Event::KeyPressed>()) {
        std::cout << "processing key\n";
        processMenuKeyPressed(*keyPressed);
    }
}
 

When I press a key I get the following output:
processing key
text enter detected
 

My understanding was that pollEvent() returns an event, which is just data. I then am interpreting that data into different types of events such as textEntered or keyPressed using the getIf with std::optional. However, the output I see in the terminal isn't what I expected, I expect to see "text enter detected" first, and "processing key" last due to the order of the if statements. Why is the order reversed? Another thing is why does the code trigger twice, and why does the code print both things?

The reason I was doing this is because I was hoping that if the menuManager accepted the textEntered event, then I would not run the keyPressed event. Am I doing something wrong, or is there a different way to get this functionality?
« Last Edit: February 01, 2025, 04:43:53 am by oz »

kojack

  • Sr. Member
  • ****
  • Posts: 359
  • C++/C# game dev teacher.
    • View Profile
Re: Window Poll Event Mechanics
« Reply #1 on: February 01, 2025, 07:59:52 am »
One event can't contain info for several different events. So only one of those ifs will be true for any call to processMenuInputs.

Under the hood, Event::TextEntered happens when SFML receives a WM_CHAR message from Windows. Event::KeyPressed happens when WM_KEYDOWN is received.

When you press a key, the WM_KEYDOWN message is sent. SFML gets it, and calls TranslateMessage (a windows function) which tries to generate a WM_CHAR message and add it to the end of the message queue. So you will always get Event::KeyPressed first, then maybe an Event::TextEntered next time you poll.
(Not all key presses can be converted to text. For example pressing an arrow key or function key won't result in a TextEntered)

Hapax

  • Hero Member
  • *****
  • Posts: 3401
  • My number of posts is shown in hexadecimal.
    • View Profile
    • Links
Re: Window Poll Event Mechanics
« Reply #2 on: February 04, 2025, 05:26:44 am »
The way to work with this would be to consider if you are expected text input and, if you are, filter all keys that would make text from the keypress section.

Remember to "unfilter" if you are no longer expected text input so that you can you use the keys for other input.
Selba Ward -SFML drawables
Cheese Map -Drawable Layered Tile Map
Kairos -Timing Library
Grambol
 *Hapaxia Links*