Author Topic: UTF-8 handling by wxSmith  (Read 5059 times)

Offline paul_c_weiss

  • Multiple posting newcomer
  • *
  • Posts: 10
UTF-8 handling by wxSmith
« on: April 07, 2016, 05:14:00 pm »
Hello!
I have been working with code::blocks 13.12 together with wxWidgets 2.8, quite satisfactorily. All my projects resort to UTF-8 encoding.
Recently, I have installed the 16.01 version together with wxWidgets 3.0.

To port my test project, I have simply manually edited the .cpb files, to have it point to the correct wxWidgets repertories.
This works quite nicely. The project complies and runs OK, with a small exception:
The accentuated characters which I have defined in the wxSmith "labels" are not correctely handled - i. e. they are not seen as UTF-8
and give the usual  character salad which appears in such cases...

Preforming some tests, I realized that replacing the _() macro by the _T() one did yield the right result (why????)

Unfortunately, wxSmith resorts to the _() macro in its automatically generated sections, which I cannot safely change.
Thus I can only correct the problem by programatically setting the label at a later stage, which is not quite satisfactory.

Is there somewhere an option that I have overlooked and which allows to get the right behaviour?
Or is this a bug?

Thanks in advance.











Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: UTF-8 handling by wxSmith
« Reply #1 on: April 10, 2016, 11:40:19 pm »

maybe this can help:
"Settings->Editor->wxSmith Settings->Other Settings->Non I18N Strings"

greetings

Offline paul_c_weiss

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: UTF-8 handling by wxSmith
« Reply #2 on: April 11, 2016, 05:26:47 pm »
Thank you!
Unfortunately, I cannot see such an option as:

"Settings->Editor->wxSmith Settings->Other Settings->Non I18N Strings"

under Code::Blocks 16:01 as downloaded...


Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: UTF-8 handling by wxSmith
« Reply #3 on: April 11, 2016, 05:38:52 pm »
it is possible that the option was added after the release...

you can try a nightly build from the forum: http://forums.codeblocks.org/index.php/topic,21090.0.html

greetings

Offline paul_c_weiss

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: UTF-8 handling by wxSmith
« Reply #4 on: April 13, 2016, 10:53:02 am »
Hello!
To avoid re-installing a nightly build, I tried and edited the following section of the project file:

<wxsmith version="1">
            <gui name="wxWidgets" src="SudokuApp.cpp" main="SudokuFrame" init_handlers="necessary" language="CPP" />
            <resources>
               <wxFrame wxs="wxsmith/Sudokuframe.wxs" src="SudokuMain.cpp" hdr="SudokuMain.h" fwddecl="0" i18n="1" name="SudokuFrame" language="CPP" />
            </resources>
         </wxsmith>

Obviously by replacing i18n="1"by i18n="0"

Is this equivalent to changing the option? - I hoped so!

Now simply rebuilding the project has no effect.
If I force a regeneration of the wxSmith-generated parts of the program, by performing a minute modification of the
.wxs file, then, after rebuilding, I get an execution error ( status -1073741819).
But wxSmith is still using the _() macro which is not satisfactory...

Do you have reason to think that the nightlx build may behave differently??

Regards,

Offline BlueHazzard

  • Developer
  • Lives here!
  • *****
  • Posts: 3353
Re: UTF-8 handling by wxSmith
« Reply #5 on: April 13, 2016, 12:54:10 pm »
installing a nightly isn't that difficult/space consuming... try it and you are sure...
NOTE: you don't install a nightly, you simply download it, unzip it and run it. You even can copy it over the release installation. BUT you need also the right dlls from the nightly forum post.

Modifying some project files by hand is no good idea. And also i don't think that this feature was implemented before the added option in the dialog, so yes i think that a nightly is behaving differently...

greetings

Offline paul_c_weiss

  • Multiple posting newcomer
  • *
  • Posts: 10
Re: UTF-8 handling by wxSmith
« Reply #6 on: April 15, 2016, 06:42:16 pm »
Thank you,

While the issue is real, I now think that I am coping with another problem, since minor modifications on my wxSmith file
cause execution errrors which cannot be corrected. What I mean is that changing a dimension (using the GUI)
induces an execution error, and then correcting back the dimension to its former value does not suppress
the error, after project re-building....

This is a totally different issue which I must now understand.
I shall later come back to the UTF-8 issue

Thanks for your help!

Offline ivan braga

  • Multiple posting newcomer
  • *
  • Posts: 15
Re: UTF-8 handling by wxSmith
« Reply #7 on: December 31, 2022, 09:24:11 am »
I know the topic is old, but the problem has not yet been resolved.

Unfortunately
maybe this can help:
"Settings->Editor->wxSmith Settings->Other Settings->Non I18N Strings"
does not work.



But editing directly as suggested
<wxsmith version="1">
            <gui name="wxWidgets" src="SudokuApp.cpp" main="SudokuFrame" init_handlers="necessary" language="CPP" />
            <resources>
               <wxFrame wxs="wxsmith/Sudokuframe.wxs" src="SudokuMain.cpp" hdr="SudokuMain.h" fwddecl="0" i18n="1" name="SudokuFrame" language="CPP" />
            </resources>
         </wxsmith>

Obviously by replacing i18n="1"by i18n="0"

it works perfectly.

Thank you, your tip helped me, it was already with your head hot.
« Last Edit: December 31, 2022, 10:21:56 am by ivan braga »

Offline Miguel Gimenez

  • Developer
  • Lives here!
  • *****
  • Posts: 1557
Re: UTF-8 handling by wxSmith
« Reply #8 on: January 01, 2023, 08:56:30 pm »
Use of i18N in wxSmith is strange:
  - The value in Settings -> Editor -> wxSmith -> Use i18N for strings looks like a global enable for translation.
  - Each wxs file has its own setting (chosen when creating the resource in the Advanced options tab) and is not modifiable without editing the CBP file.

Both settings are ANDed in wxscodinglang.cpp:185, if the result is true then the string is surrounded with _(), if not with the value selected in Settings -> Non i18N strings.

This behaviour is unexpected and should be clarified, probably Use i18N for strings should be changed to Enable i18N globally or similar wording.