SFML community forums

Help => Window => Topic started by: tntexplosivesltd on May 27, 2011, 05:17:44 pm

Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 27, 2011, 05:17:44 pm
Hi there
Is there any way to get sf::Event to return the scancode of the key that was pressed?
Thanks
Title: sf::Event return key pressed
Post by: Laurent on May 27, 2011, 06:06:08 pm
No.

What do you want to do with a scan code?
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 27, 2011, 06:07:43 pm
Well, I want to make it so that the user can type in a text area.
Title: sf::Event return key pressed
Post by: Laurent on May 27, 2011, 06:12:08 pm
And how would a scan code help implementing this?

sf::Event::TextEntered is what you're looking for.
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 05:08:28 am
Hmm, that uses unicode. I am only wanting to use ASCII (I am writing my own text methods with OpenGL).
Title: sf::Event return key pressed
Post by: OniLinkPlus on May 28, 2011, 05:43:28 am
Quote from: "tntexplosivesltd"
Hmm, that uses unicode. I am only wanting to use ASCII (I am writing my own text methods with OpenGL).
Unicode's first 128 characters (0x00 to 0x7F) are equivalent to ASCII. Just discard any characters greater than 127.
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 06:10:29 am
Nono, the whole point of me using ASCII was for the extended ASCII.
Title: sf::Event return key pressed
Post by: Laurent on May 28, 2011, 10:08:31 am
"Extended ASCII" alone doesn't mean anything. There are many different extended ASCII encodings.

And I still don't see how scan codes may help you...
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 11:44:38 am
I realised I don't need scan codes, I need to get the character that the user entered.
I know about extended ASCII, I am using the extended Windows-1252 set (the most common I am told).
So I need to find out what ASCII character the user endered in. I'm not sure how european keyboards differ from ours, so I might just be able to use UTF-8 (well, the first 127 characters of UTF-32). I users to be able to use the letters with accents and thinks like that, if they need to.
Title: sf::Event return key pressed
Post by: Laurent on May 28, 2011, 12:15:56 pm
Why do you make things so complicated? Just keep a Unicode encoding; SFML gives you UTF-32 characters but you can easily convert to UTF-8 or UTF-16. It depends what classes you use to display your text, and what encodings it can work with.
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 01:06:50 pm
To display the text, I am using OpenGL display lists. I have a Windows-1252 extended character-set texture which I get the character image from. The ascii number of the character represents the display list I need to draw.
Title: sf::Event return key pressed
Post by: Laurent on May 28, 2011, 02:15:09 pm
Windows-1252 will make things very complicated for you. SFML doesn't provide anything to convert to it, so you'll need to write your own conversion function or find a library or piece of code that does it.

If possible, I suggest you generate a bitmap font using another encoding. Latin-1 (ISO 8859-1) is a good choice: it's defined by the 256 first characters of the Unicode standard, so no conversion is required to convert from UTF-32.
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 02:40:51 pm
Hmm, turns out ISO 8859-1 is Windows-1252, it's just commonly mislabeled as ISO 8859-1. So there's no problem.
So I just need to use a sf::Unicode::UTF32String and turn it into a character array? Or can I use a character array right off the bat? (My function takes a pointer to a character array).
Title: sf::Event return key pressed
Post by: Laurent on May 28, 2011, 02:53:59 pm
Quote
Hmm, turns out Windows-1252 is ISO 8859-1, it's just commonly mislabeled as ISO 8859-1. So there's no problem.

Oh, indeed you're right. Well, strictly speaking it's not ISO 8859-1, it's an extension to it (it replaces some control characters with printable characters). It's good to know.

Quote
So I just need to use a sf::Unicode::UTF32String and turn it into a character array? Or can I use a character array right off the bat? (My function takes a pointer to a character array).

You can use an array of [unsigned] char directly if you want.
Code: [Select]
std::basic_string<unsigned char> chars;

event loop...
{
    if (event.Type == sf::Event::TextEntered)
    {
        if (event.Text.Unicode < 256)
            chars += static_cast<unsigned char>(event.Text.Unicode);
    }
}
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 03:21:10 pm
Ah cool! Thanks. Is it possible to do it without using the STL? (I'm trying to avoid it - it's horrible at times). Can it be done using just char[]?
Title: sf::Event return key pressed
Post by: Laurent on May 28, 2011, 03:27:59 pm
Do whatever you like. You can get a Windows-1252 unsigned char from SFML, what you do then is between you and your code ;)

But... Saying that the STL is horrible sounds like a beginner statement (beginners always fight against the STL). I doubt that you'll write less horrible code with a raw array. Unless you do something very limited or something that will crash at users face.
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 28, 2011, 03:43:21 pm
I don't agree. Some very good code can be written without using the STL. I don't need a lot of flexibility (not that STL is that flexible, you must play by its rules), and the added complexity just isn't worth it. Plus, it can be slower than raw arrays at times, especially when you don't need them.
But, I don't want to start a war.
Thanks for the help!
Title: sf::Event return key pressed
Post by: Nexus on May 28, 2011, 04:46:24 pm
Quote from: "tntexplosivesltd"
I don't agree. Some very good code can be written without using the STL. I don't need a lot of flexibility (not that STL is that flexible, you must play by its rules), and the added complexity just isn't worth it.
The complexity on user side is actually much lower than when you handcraft it.
Code: [Select]
std::string s = GetString() + "xyz";
s.erase(2);
std::string t = s;
unsigned int n = std::count(t.begin(), t.end(), 'x');
vs.
Code: [Select]
char s[20];
std::strcpy(s, GetString());
std::strcat(s, "xyz");

unsigned int len = std::strlen(s);
for (unsigned int i = 2; i != len; ++i)
    s[i] = s[i+1];

char t[20];
std::strcpy(t, s);

unsigned int n = 0;
for (unsigned int i = 0; i != len; ++i)
    if (t[i] == 'x')
        ++n;

Plus, at every strcpy() and strcat() we have the omnipresent risk of buffer overflows. And this is only a simple example with static arrays. When you need dynamic allocations (because you don't know the string length in advance), the C version is even funnier, since ownership management and exception safety become real issues.

Quote from: "tntexplosivesltd"
Plus, it can be slower than raw arrays at times, especially when you don't need them.
It can of course be, but normally statements like this only arise if the compared functionality is not equivalent. It can as well be faster, as strlen(s) vs. s.length() shows well.
Title: sf::Event return key pressed
Post by: regicide on May 29, 2011, 04:02:48 am
Quote from: "Laurent"
But... Saying that the STL is horrible sounds like a beginner statement (beginners always fight against the STL). I doubt that you'll write less horrible code with a raw array. Unless you do something very limited or something that will crash at users face.

It depends on what you are doing, however in the case of a string holding user supplied input it is often much 'safer' than a char[]s.

Quote from: "Nexus"
Plus, at every strcpy() and strcat() we have the omnipresent risk of buffer overflows. And this is only a simple example with static arrays.

Would a memcpy not suffice if you know the maximum size?

Quote from: "Nexus"
When you need dynamic allocations (because you don't know the string length in advance),
the C version is even funnier, since ownership management and exception safety become real issues.

Is it not rather redundant talking about exception safety when the point of using the c alternative is to avoid the STL, where exactly would these exceptions be thrown from?
RAII negates most of this issue, unless your destructors are throwing exceptions that is, in which case you are screwed either way.

Quote from: "tntexplosivesltd"
I don't agree. Some very good code can be written without using the STL. I don't need a lot of flexibility and the added complexity just isn't worth it.

Well said. The flexibility can come at a huge cost when you factor in GCC's fantastic compile time messages regarding the STL.

Nexus' point is also valid concerning strings, however the argument does not hold as strongly for the entirety of the STL.

Although it is often silly to avoid using the STL entirely, it is extremely wise to consider the alternatives (even more so in real-time applications). It is rarely a good idea to use a library utility when a language construct achieves the goal sufficiently.
The right tool for the job after all.

~Chris
Title: sf::Event return key pressed
Post by: Laurent on May 29, 2011, 10:46:38 am
Stop focusing on the STL. My point was more about using abstractions when possible, rather than manual memory management. Whether it is the STL, boost, Qt or whatever doesn't matter, but there's really no reason to write complicated, error-prone and unsafe code when easy abstractions are available.

That's the important thing; don't start a war against STL please ;)
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 29, 2011, 10:49:40 am
Quote from: "tntexplosivesltd"

But, I don't want to start a war.
Title: sf::Event return key pressed
Post by: Nexus on May 29, 2011, 12:09:47 pm
Quote from: "regicide"
Would a memcpy not suffice if you know the maximum size?
Yes, but then there is the risk that the null termination is not copied (or some nonsense after it is copied, which is less problematic).

Quote from: "regicide"
Is it not rather redundant talking about exception safety when the point of using the c alternative is to avoid the STL, where exactly would these exceptions be thrown from?
The STL hardly throws exceptions. std::out_of_range, std::length_error, std::bad_alloc occur very rarely when your program is correct. User-defined exceptions are the bigger problem.

Quote from: "regicide"
Nexus' point is also valid concerning strings, however the argument does not hold as strongly for the entirety of the STL.
But there are a lot of examples. E.g. std::vector has so many advantages over new[] and delete[]. And when one needs more specific data structures like linked lists or maps, reinventing the wheel is even less worth the trouble.

It is true, the right tool for the right job. The STL is not always the best solution, but it covers a lot of cases. And before one falls back to error-prone low-level mechanisms, there should be good reasons. And "having heard that char[] is faster than std::string" is none ;)
Title: sf::Event return key pressed
Post by: tntexplosivesltd on May 29, 2011, 02:14:53 pm
Quote from: "tntexplosivesltd"

But, I don't want to start a war.

Quote from: "Laurent"

don't start a war against STL please
Title: sf::Event return key pressed
Post by: Nexus on May 29, 2011, 02:31:12 pm
War? I just explain how I see things. When you say "the STL is unflexible, more complex and slower than the manual approach", you don't have to wonder when you're corrected. Myths like this are already spread enough in the C++ community.

By the way, there is no need to play the policeman :roll:
Title: sf::Event return key pressed
Post by: Laurent on May 29, 2011, 03:01:37 pm
I will play the policeman. The OP clearly said "no war" and people can't stop debating about this, so I lock the topic.

There are too many endless topics like this one on the internet, there's really no need to start a new one.