sf::Event::TextEvent producing '\v' when Enter is pressed, instead of '\n'?

[Clairvoire]

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)

[Jesper Juhl]

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).

[czaloj]

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.

[Laurent]

You really followed the standard.

I'm curious to know which standard.

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.

[czaloj]

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;
     // ...
 

[eXpl0it3r]

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.

[czaloj]

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.

[eXpl0it3r]

Another example of standard text input:

There's not "standard" so you should stop using that word in this context.

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:

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.

[czaloj]

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.

[Rosme]

Events Explained
Directly after the code snippet.

[czaloj]

Yeah, not really:
http://www.sfml-dev.org/documentation/2.2/structsf_1_1Event_1_1TextEvent.php#a00d96b1a5328a1d7cbc276e161befcb0

[BlueCobold]

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.