wxlocale corrupts my mesh files?! Topic is solved

[phlox81]

Hm, would you have a link to that osg stuff, so I could take a look at that lib?

Well, to do it the STL way, first, whats line in this case?
I guess its a pointer, maybe char*

First, you should try to get that line into a stream.

Code: Select all

std::string temp(line+2); // not sure if that works, you should somehow put the line into an std::string, if they don't use std::istream to read the data. (then, you can use that stream to read, instead of stringstream.
std::stringstream str(temp);
float v1,vn;
str >> v1 >> vn;

[Vexator]

aah this looks familiar somehow

line is an array of char:

Code: Select all

const int LINE_SIZE = 4096;
char line[LINE_SIZE];

this is the latest stable release:
http://www.openscenegraph.org/downloads ... OT-1.0.zip

take a look at OpenSceneGraph/src/osgPlugins/obj/obj.cpp, especially at the Model::readOBJ and Model::readMTL functions.

if you happen not to know the .obj format:
http://www.zib.de/javaview/guide/format ... t_Obj.html

(the .obj file format is of course just one example, this issue is critical for every ascii files loaded)

thanks for your support so far!

[utelle]

ok, first of all, i'll give the stl idea a try. osg's .obj importer uses sscanf to read in data. what would you suggest as an stl alternative now? (i have to admit that i barely ever used stl):

Code: Select all

sscanf(line+2,"%f %f %f %f", &x, &y, &z, &w);

If you want to make the osg stuff locale safe you would have to change a lot of places in the osg code. And you would have to redo it every time a new osg version is released. You're sure this is the way you want to go?

I think there might be a third option, if you're only interested in getting string translations according to the user locale. You could proceed as follows:

1) Allocate a wxLocale object and keep a pointer to it where you can access it globally,
2 Set the locale you need, i.e. german locale, using the Init method of your wxLocale object,
2) Load the needed message catalog file(s)
3) Restore the C locale (allocate a wxLocale object, call Init with wxLANGUAGE_ENGLISH)
4) Write a replacement for wxGetTranslation so that it refers to your locale for which you loaded the message catalogs, and redefine the macro _() to use your replacement function.
5) When exiting your application delete the locale created in 3) and thereafter the locale created in 1)

This should give you translated message without the need to modify the osg code.

I wouldn't recommend to temporarily change the locale while loading files due to the possible unwanted side effects.

.. for example?

At least in a multithreaded environment you might get errors when converting doubles to strings or vice versa since the decimal separator might be different unexpectedly.

Regards,

Ulrich

[Vexator]

so the first wxlocale (the one which i assign the chosen language to) will be used to translate strings, while the 2nd one will be used by the c functions? sounds like it could work, but it's actually an ugly hack, isn't it? :/ is this really better than simply deactivating wxlocale and then re-activating it? i'm not concernced about multithreading issues, i'm not going to use threads at all, but i'll keep your advise in mind.

i'll give the double locale idea a try when i'm home, but i'd still like to test if editing osg to use stl functions instead of standard c functions will do the trick as well.

btw.. if osg uses standard c functions to do the conversions all the time, why is the comma and dot stuff a problem at all? i would understand it if the conversion between data read with c functions is then processed with stl functions or vice versa.. but if standard c functions are used exclusively, why does the conversion fail?

[utelle]

so the first wxlocale (the one which i assign the chosen language to) will be used to translate strings, while the 2nd one will be used by the c functions? sounds like it could work, but it's actually an ugly hack, isn't it? :/ is this really better than simply deactivating wxlocale and then re-activating it?

The advantage is you do it only once on startup of your program - and it will work even in multithreaded environments. Of course it's a hack ... but is changing countless places in osg code any better?

but i'd still like to test if editing osg to use stl functions instead of standard c functions will do the trick as well.

Good luck. You'll see it's a lot of work and you'll have to very careful not to break osg code.

btw.. if osg uses standard c functions to do the conversions all the time, why is the comma and dot stuff a problem at all? i would understand it if the conversion between data read with c functions is then processed with stl functions or vice versa.. but if standard c functions are used exclusively, why does the conversion fail?

The osg code assumes the decimal separator to be always a decimal point. There are places in the osg source where strings are parsed to identify the datatype without the use of standard C functions. Floating point numbers are identified by looking explicitly for a decimal point. But the real conversion takes place using standard C functions. If you change the locale for example to german the decimal separator will be a comma. So at one place or the other the code will not function properly.

Regards,

Ulrich