Developer forums (C::B DEVELOPMENT STRICTLY!) > Plugins development

error in wxSmith - wxsitem.cpp

(1/3) > >>

frithjofh:
Hi everybody,

I found a bug in wxSmith. It affects the code generated by wxsitem.cpp line 793. There a double value is streamed into a wxString using the << operator. In some cases this leads to wrong results, I think depending on the localization of the OS.

For instance in the case of a wxSplitterwindow one can give a value for the sash gravity in the properties grid. The value has to be given as decimal value with a comma as decimal separator, point is not accepted. The value is correctly transmitted to the according wxs file, using a comma as decimal separator too. This value gets treated in wxssplitterwindow.cpp , where it is converted from wxString to double, from there a call to a function codef in wxsitem.cpp is done. In the above mentioned line 793 in wxsitem.cpp the double value is attached to the wxString representing the actual code in the source file produced by wxSmith. There the operator << is used for the matter. The problem is, the correct double value is changed to a string with a comma as separator and appears like that in the generated code instead of a string with a point decimal separator as it should be.
Compiling the generated code gives an error complaining about no known function SetSashGravity with two ints as arguments.

I'm encountering this behavior on a SuSE 12.1 x64 localized in German language using the last svn version 7930.

Regards

frithjofh

frithjofh:
on my locale copy of wxSmith source I introduced a change hopefully resolving the problem: in the actual function holding the logic of code generation y put a new line at the beginning: setlocale(LC_NUMERIC, "C"); and another new line at the end: setlocale(LC_NUMERIC, "");

this sets the locale during all of the code generation and then restores it to what it was before. might not be the right way, nor the right place, but as setlocale() is ANSI standard I think it is portable.

on my machine and os it resolves my problem, but I have too little experience to know if this is the right way. I would think there was a more central point in wxSmith up the flow of code generation were a change should be made.

opinions please...

regards

frithjofh

oBFusCATed:
Using setlocale(...) is a hack, which should not be used, because it will break code running in other threads or code running in a wx event.

frithjofh:
Oh well,... there's always something.

Haven't thought about neither, really. But the problem is a real one I think. All functions in code::blocks which do textual code generation face it.

So would it be the way to change just the function, to not rely on operator<< , not mingle around with locales, but to parse the given strings themselves and watch for correct decimal separator in the output?

regards

frithjofh

oBFusCATed:
I'm not really sure what is the correct approach here. :(

Navigation

[0] Message Index

[#] Next page