SFML community forums
Help => Window => Topic started by: Skomakar'n on May 25, 2011, 07:39:47 am
-
I've made a textfield that works pretty well, and under Linux, if it happens to deal with characters that don't add anything to the width of the rectangle around the rendered text, it simply doesn't store them. I don't know why Greek or Cyrillic characters won't work as I'm using wide character strings, so this is also something I would like to get an answer to. Many other characters, such as þ, ð, å, ä, ö, æ and ø work just fine.
The main problem here, though, is that when trying to type Greek or Cyrillic characters when running the program in Mac, the program will simply crash. This is the call stack that Xcode gave me (read from bottom to top):
(http://gyazo.com/4d52a216e53cf30a5edba3ef045e2bb9.png)
Also, accented letters don't get noticed by OS X, but they work fine under Linux; that is, in Linux, I can, for instance, first press the grave accent key, and then the A key, and an á will actually appear in my textfield. OS X ignores the accent key and just gives me a regular a.
-
Which SFML version are you using ?
-
Oh, sorry. 1.6. I'm running Snow Leopard on an Intel-based MacBook Pro. The problem has nothing to do with the textfield code or the TextEntered event. I booted up an old demo of the game, and it crashed as soon as I pressed a letter key using a Greek or Russian keyboard layout, too. As you can see in the call stack above, the bug is in SFML.
-
I think we would need a minimal example producing this crash, because I've just been testing Greek or Russian keyboard layout and nothing special happened.
I dunno whether there's something particular to do, I've only used the default Window-based project and typed some letters with both layouts.
-
I think we would need a minimal example producing this crash, because I've just been testing Greek or Russian keyboard layout and nothing special happened.
I dunno whether there's something particular to do, I've only used the default Window-based project and typed some letters with both layouts.
It appears it doesn't happen if I compile using the terminal, but only when I compile using Xcode (Debug or Release mode doesn't matter)...
Any project, for that matter, as long as it uses a RenderWindow, at least.
-
Hmm.. indeed it does crash with the graphics project. I'll have a look at it but not right now.
-
Does this problem happen also with 2.0 ? (If you have time to test)
-
Does this problem happen also with 2.0 ? (If you have time to test)
I don't have SFML 2, sorry (and I don't intend on getting it for this project; I've written probably fifteen to sixteen thousand lines so far... No way I'm changing all of that now, haha).
-
We're not asking you to convert your project, we just want you to test this particular problem with SFML 2 ;)
But if it can be reproduced easily, I guess Hiura or Ceylo can try it as well.
-
Seems to work fine with SFML2 (at least no crash).
-
Seems to work fine with SFML2 (at least no crash).
Thank you =)
-
Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0xf0b1b15e
0x0028a243 in sf::Input::OnEvent (this=0xbffff4a0, EventReceived=@0xbfffefc4) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/Input.cpp:112
112 case Event::KeyPressed : myKeys[EventReceived.Key.Code] = true; break;
(gdb) bt
#0 0x0028a243 in sf::Input::OnEvent (this=0xbffff4a0, EventReceived=@0xbfffefc4) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/Input.cpp:112
#1 0x0028d023 in std::_Rb_tree_const_iterator<sf::WindowListener*>::operator++ () at /Developer/SDKs/MacOSX10.5.sdk/usr/include/c++/4.0.0/bits/stl_tree.h:193
#2 0x0028d023 in sf::priv::WindowImpl::SendEvent (this=0x30b1bcba, EventToSend=@0xbfffefc4) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/WindowImpl.cpp:191
#3 0x0028f5c1 in sf::priv::WindowImplCocoa::HandleKeyDown (this=0x51a7e0, eventRef=0x53a3a0) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/Cocoa/WindowImplCocoa.mm:284
#4 0x9458ed38 in -[NSWindow sendEvent:] ()
#5 0x944a7817 in -[NSApplication sendEvent:] ()
#6 0x0028e298 in -[sfPrivAppController processEvents] (self=0x509e90, _cmd=0x2ca6b9) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/Cocoa/AppController.mm:397
#7 0x0028fe27 in sf::priv::WindowImplCocoa::ProcessEvents (this=0x51a7e0) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/Cocoa/WindowImplCocoa.mm:557
#8 0x0028b81b in sf::Window::GetEvent (this=0xbffff470, EventReceived=@0xbffff83c) at /Users/ceylo/Downloads/SFML-1.6-sdk-macosx-ub32+64/build/xcode/../../src/SFML/Window/Window.cpp:222
#9 0x000025ce in main ()
(gdb) print EventReceived.Key.Code
$1 = 816954554
:roll:
-
EventReceived.Key.Code must have an invalid value.
Anyway, if it works with SFML 2 it's not going to be fixed in 1.6, so don't waste too much time on this crash.
-
EventReceived.Key.Code must have an invalid value.
Anyway, if it works with SFML 2 it's not going to be fixed in 1.6, so don't waste too much time on this crash.
If Ceylo feels up to fixing it anyway, though, you're not going to stop him, are you, haha?
Maybe he doesn't, though...
-
I won't stop him but there will be no release containing this fix ;)
-
Good to hear that it doesn't happen with 2.0, at least.
If you happen to find a fix, anyway, Ceylo, please tell me, and I guess I could try to recompile it myself (or you could just give me an updated framework or whatever).
-
Actually I'm kind of stuck because I can't get the graphics sample to crash anymore.
Maybe I shouldn't have installed Xcode 4 but.. anyway I don't get any crash. I check the Key.Code values and I always get something between 0 and sf::Key::Count (most are 0 though). So I don't really know what to think.
Edit: even with GuardMalloc enabled, it won't crash. If any under/overflow had happened it would have immediately crashed.