SFML community forums

Help => Window => Topic started by: Clairvoire on August 18, 2014, 08:16:33 am

Title: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: Clairvoire on August 18, 2014, 08:16:33 am
When inspecting a 'text entered' event, the integer I get from sf::Event::TextEvent::unicode is 13, for carriage return.  I would've expected this to be 10, or '\n' for newline. 

Is this intended, or is something going wrong here?  (I've never encountered a carriage return before, so this took me a bit by surprise)
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: Jesper Juhl on August 18, 2014, 08:37:37 am
I'm guessing this is a confusion about number bases.
Vertical tab is 11 (decimal), 13 (octal) and carriage return is 13 (decimal), 15 (octal).
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: czaloj on March 11, 2015, 03:14:51 pm
I'm gonna post this here since it's kinda on the same topic:

    WTF SFML!!!!! You send enter/tab/backspace as text events... really? I converted a text handler to an SFML implementation (it works perfectly with SDL and GLFW text events), and lo and behold... it doesn't work as I planned. Thank you dev(s). ..|.. You really followed the standard.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: Laurent on March 11, 2015, 05:04:58 pm
Quote
You really followed the standard.
I'm curious to know which standard.

Quote
WTF SFML!!!!! You send enter/tab/backspace as text events... really?
We just forward what the OS generates for its corresponding native event (WM_CHAR on Windows, for example). It's not SFML that decides what is suitable for the TextEntered event, it's the OS.

And no need to be so rude, just filter out the characters that you don't need... There are useful functions for that in the standard library.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: czaloj on March 11, 2015, 11:58:39 pm
Sorry, much of my anger is because of some guy in my project being an SFML purist. It's just that when you say TextEvent - I expect text:

void _glfwInputChar(_GLFWwindow* window, unsigned int codepoint, int mods, int plain)
{
    if (codepoint < 32 || (codepoint > 126 && codepoint < 160))
        return;
     // ...
 
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: eXpl0it3r on March 12, 2015, 12:09:34 am
As Laurent said, SFML's TextEntered event is using what the OS provides. Whether you've a different expectation or not, is nothing we can influence by any means.
This also means that the event is not limited to ASCII, but instead will return unicode characters as well.

And last but not least \n, \t and even \b are in my opinion text characters as well.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: czaloj on March 12, 2015, 12:13:30 am
Another example of standard text input:

int
SDL_SendKeyboardText(const char *text)
{
    SDL_Keyboard *keyboard = &SDL_keyboard;
    int posted;

    /* Don't post text events for unprintable characters */
    if ((unsigned char)*text < ' ' || *text == 127) {
        return 0;
    }
 

I guess I'm just saying it would be nice if you adhered to what other APIs are doing for text events, call it some other event type, or EMPHATICALLY state what your function is doing.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: eXpl0it3r on March 12, 2015, 12:22:34 am
Quote from: czaloj on March 12, 2015, 12:13:30 am
Another example of standard text input:
There's not "standard" so you should stop using that word in this context. ;)

Quote from: czaloj on March 12, 2015, 12:13:30 am
I guess I'm just saying it would be nice if you adhered to what other APIs are doing for text events, call it some other event type, or EMPHATICALLY state what your function is doing.
We don't change implementations just because other libraries do it differently. We provide what the OS provides and if something doesn't suit the user's need, they can very easily filter it out themselves. If we were filtering by default and someone wanted to use the events, they'd have to edit SFML's source code to achieve what they want. As such the current implementation gives more freedom to the user.

And it is emphasized in the tutorial:
Quote from: Official Event Tutorial (http://www.sfml-dev.org/tutorials/2.2/window-events.php#the-textentered-event)
Note that, since they are part of the Unicode standard, some non-printable characters such as backspace are generated by this event. In most cases you'll need to filter them out.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: czaloj on March 12, 2015, 12:26:56 am
Ok, would you please link this kind of information to the documentation, because it is not clear as it currently stands. I never stumbled on that tutorial as I looked at your docs.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: Rosme on March 13, 2015, 04:04:17 pm
Events Explained (http://www.sfml-dev.org/tutorials/2.2/window-events.php#the-textentered-event)
Directly after the code snippet.
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: czaloj on March 16, 2015, 06:17:13 am
Yeah, not really:
http://www.sfml-dev.org/documentation/2.2/structsf_1_1Event_1_1TextEvent.php#a00d96b1a5328a1d7cbc276e161befcb0
Title: Re: sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?
Post by: BlueCobold on March 21, 2015, 08:19:08 pm
Sorry, but in my eyes not sending \r, \t or \b like SDL does, to me is a bug. They are characters you enter by pressing keys on your keyboard. Different applications will handle these keys differently (IDE vs. Browser for example), but the framework shouldn't decide about what the application wants to do with the entered key, the application should. Freedom to the developer is the key here.