Messages

1

Window / Re: On Windows, WM_CHAR is being used instead of WM_UNICHAR

« on: March 13, 2013, 10:00:18 am »

Cool! Issue tracker post!

I also think opening files in SFML with Unicode paths will not work on Windows, but that's an issue that I will look into on another day, and I will forgive you for not getting enthusiastic about it. Windows makes handling Unicode paths in a cross-platform way really evil (UTF-8 works by default for file paths on every other OS, I believe, but the Windows platform does not support UTF-8 and provides no way to use Unicode paths in a way that conforms with the C/C++ standard).

2

Window / Re: On Windows, WM_CHAR is being used instead of WM_UNICHAR

« on: March 13, 2013, 09:18:21 am »

As far as I know, asian languages are in the BMP. The SMP rather contains dead languages and things like emoticons.

That is not true. For instance, the CJK Unified Ideographs Extension B contains many characters widely used in Hong Kong, and many of the characters used for Chinese and Japanese names are not in the BMP. I did my research, and realized if I didn't pay attention to these facts, people would hate me.

3

Window / Re: On Windows, WM_CHAR is being used instead of WM_UNICHAR

« on: March 13, 2013, 08:26:14 am »

Thanks for the reply. I recently read up on real-world Unicode usage in software after wanting to make sure my software would have the broadest potential audience. Apparently supporting code points outside of the BMP is important to some people, particularly those who use Asian languages on their computers.

Obviously the cost/benefit decision is up to you, but my research led me to believe that code points outside the BMP may not be as obscure as it might seem to a speaker of Western languages. And technically, assuming UTF-16 is UTF-32 is a bug. Also, converting from UTF-16 to UTF-32 is like 3 lines of code, I think.

4

Window / On Windows, WM_CHAR is being used instead of WM_UNICHAR

« on: March 13, 2013, 04:30:06 am »

I noticed in the 2.0 source code, in WindowImplWin32.cpp line 515, WM_CHAR is being used to set event.text.unicode. The SFML documentation says that event.text.unicode is supposed to be UTF-32 (ie. the library user always gets a plain, unencoded code point). However, the MSDN documentation for WM_CHAR says that the application receives UTF-16, and notes that "The WM_UNICHAR message is the same as WM_CHAR, except it uses UTF-32."

Shouldn't SFML be using WM_UNICHAR?

5

General / Re: CMake not outputting static build files for VS2005

« on: March 12, 2013, 11:55:44 pm »

There we go. It was cmake-gui's fault. Thanks for your attention.

PS. The Graphics module doesn't compile in VS2005 due to one of the precompiled .lib dependencies, but I don't need that module.

6

General / Re: CMake not outputting static build files for VS2005

« on: March 12, 2013, 11:47:26 pm »

I can't find anything wrong in the CMake files, they're pretty straightforward. Now that I'm triple-checking everything, I think cmake-gui got messed up somehow when I mistyped a directory name. I'm going to try running it one more time...

7

General / Re: CMake not outputting static build files for VS2005

« on: March 12, 2013, 11:21:25 pm »

I have my reasons for sticking with VS2005. And I use a lot of libraries, and none of them care what version of VS I use, including those that use CMake. That's the whole point of CMake, I thought.

8

General / [solved] CMake not outputting static build files for VS2005

« on: March 12, 2013, 10:58:07 pm »

CMake is not outputting static build files for VS2005. I unchecked BUILD_SHARED_LIBS and the resulting project files are identical to the ones where that option is checked, and thus the resulting project files only build the shared libs.