Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Run-time error: setlocal en_us #135

Open
marued opened this issue Jan 25, 2019 · 3 comments
Open

Run-time error: setlocal en_us #135

marued opened this issue Jan 25, 2019 · 3 comments

Comments

@marued
Copy link

marued commented Jan 25, 2019

I'm using the STEP importer in one of my project and I wanted to update the IfcPlusPlus to it's latest greatest. I'm encountering a new run time issue where a check is made to check the language setting of the system in the file ReaderSTEP.cpp line 79 to make sure the system has the local language en_us set. Obviously, my windows 10 system is not set to English and hence this line fails.

Why is this check made? and is it really wise to restrict the users to a single language setting? This could be a deal breaker for a lot of users.

Thanks in advance.

@marued
Copy link
Author

marued commented Jan 25, 2019

Actually, it's possible the call actually requires admin rights on windows. My current user does not have the proper rights to change the local...

@Fed80
Copy link

Fed80 commented Feb 19, 2019

I solved replacing "en_us.UTF-8" with "en-US".

"The locale argument can take a locale name, a language string, a language string and country/region code, a code page, or a language string, country/region code, and code page. The set of available locale names, languages, country/region codes, and code pages includes all those supported by the Windows NLS API except code pages that require more than two bytes per character, such as UTF-7 and UTF-8. If you provide a code page value of UTF-7 or UTF-8, setlocale will fail, returning NULL." link to microsoft page

@berndhahnebach
Copy link
Contributor

Why is this check made? and is it really wise to restrict the users to a single language setting? This could be a deal breaker for a lot of users.

Would like to know this one too. Compiling fails on Debian with this switch. I got around by using the old behaviour if setlocale fails: berndhahnebach@8429dc2

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants