SFML community forums
Help => Window => Topic started 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
-
No.
What do you want to do with a scan code?
-
Well, I want to make it so that the user can type in a text area.
-
And how would a scan code help implementing this?
sf::Event::TextEntered is what you're looking for.
-
Hmm, that uses unicode. I am only wanting to use ASCII (I am writing my own text methods with OpenGL).
-
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.
-
Nono, the whole point of me using ASCII was for the extended ASCII.
-
"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...
-
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.
-
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.
-
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.
-
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.
-
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).
-
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.
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.
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);
}
}
-
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[]?
-
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.
-
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!
-
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.
std::string s = GetString() + "xyz";
s.erase(2);
std::string t = s;
unsigned int n = std::count(t.begin(), t.end(), 'x');
vs.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.
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.
-
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.
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?
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.
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
-
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 ;)
-
But, I don't want to start a war.
-
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).
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.
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 ;)
-
But, I don't want to start a war.
don't start a war against STL please
-
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:
-
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.