There is utf8 garbled code when generating code and some suggestions.

[D22699]

1 / about the problem that object properties do not support utf8 naming.

The string naming in property already supports utf8, but the event name named in events does not support utf8 naming, resulting in There is a garbled code in the naming of CPP code The UTF8 string in the H file is displayed normally.

2 / in the lower right corner, the comment of the attribute line is displayed. I hope it can support copying text.

3 / I hope wxforbuilder can support language packs, solve menus, properties, components, etc., and support multiple languages. If there are official language pack files, we can provide Chinese sentence translation.

4 / I hope you can release the annotation, so that users can have an annotation window, provide annotation mapping expressions, and configure custom annotations for all components.

5 / in the F1 help menu, write the relevant updated contents of the historical version.

6 / support other function extensions. For example, if comments can be customized, can Wx component function names also map other utf8 names or support aliases?

I hope wxformbuilder can be updated in the next version.

thank! thank! thank!

[D22699]

@jhasse @sodevel

update request (Garbled code problem)

1 / about the problem that object properties do not support utf8 naming.

The string naming in property already supports utf8, but the event name named in events does not support utf8 naming, resulting in There is a garbled code in the naming of CPP code The UTF8 string in the H file is displayed normally.

It may be a Lua script problem

thank! thank! thank!

[sodevel]

1. There was a problem in the code generator that broke multibyte encoded UTF-8 characters that affected e.g. chinese characters, but this was fixed in 2d20e71. I can't confirm your observations and actually do not understand your description where they do happen.
2. That box in the lower right corner that displays the attribute help strings is part of wxPropertyGrid, i don't see an option to enable copying from it. You have to ask the wxWidgets people to implement such a feature.
3. There are so many other issues to solve first and wxFB uses the translation macros very wrong, this won't happen in the near future.
4. I don't understand what that means
5. To reduce the workload i stopped shipping release notes with the application but try to list relevant information on the GitHub release page
6. Again i don't understand what that shall be

[D22699]

1 / about the problem that object properties do not support utf8 naming.

The string naming in property already supports utf8, but the event name named in events does not support utf8 naming, resulting in There is a garbled code in the naming of CPP code The UTF8 string in the H file is displayed normally.

[D22699]

2 / in the lower right corner, the comment of the attribute line is displayed. I hope it can support copying text.

That box in the lower right corner that displays the attribute help strings is part of wxPropertyGrid, i don't see an option to enable copying from it. You have to ask the wxWidgets people to implement such a feature.

wxPropertyGrid (don't see an option to enable copying from it) no way

wxTextCtrl open Editable status, Support replication.

[D22699]

No language pack
menu/Right click menu/wxPropertyGrid，
Can't translate

Add right-click menu

Copy Wx component name (first)
Jump to official Wx component file (secondary)

[D22699]

@jhasse@sodevel

update request (proposal)

picture1，the event name named in events does not support utf8 naming.
picture2，wxTextCtrl open Editable status, Support replication.
picture3，Support language pack，support Add right-click menu.
picture3，It is recommended that wxtreectrl right click to jump to CPP line,
..................

4.1/ Want events to support utf8 custom annotations
for example “OnButtonClick”

m_button1->Connect( ***, wxComm ***( MyFrame1::Click1 ), ***, *** );
//这是一个单击事件（custom）
//This is a click event（custom）

4.2/Add start and end annotation pairs to the "Sizer"
wxBoxSizer* bSizer1;
bSizer1 = new wxBoxSizer( wxVERTICAL );
// bSizer1 start

..................

// bSizer1 end

[sodevel]

About your question 1, this is already fixed, but there is no new release available that contains the fix. From your screenshots i see you are using Windows, you can use a recent build made by the Github CI, just browse to the Actions section and download a windows build from one of the recent workflow runs.

About question 2, this is NOT a wxTextCtrl, this box is part of the wxPropertyGridManager, a component of wxWidgets, and this doesn't offer an API to make that text selectable, so i can't do anything about it.

About question 4, i don't think this can be easily done and i also can't imagine what this would be useful for. The generated code should be completely unimportant for the user, he should never have the need to look at it, why should it be annotated? Especially the user should not modify the code at all, all customization must happen in the derived class (in the C++ case, it might be a bit different for the other languages, but even there, the generated code should not be touched).

Now your biggest topic, localization. From your questions and the screenshots i get the impression you are on the wrong track about how localization can and should be done. There are two different parts in wxFB that need to be taken care of during localization, the source code and the xml definitions.

wxFB uses wxWidgets and that uses gettext for localization. Basically you let gettext run over the source code to create a message catalog definition. This one you use to create the different message catalogs for each target language. wxWidgets offers a mechanism to mark strings in the source code for translation to create that message catalog definition and also to load the message catalogs. However, the source code of wxFB uses the macro to mark the strings for translation wrong, most of the time it is used in the reversed purpose, it marks strings for translation that MUST NOT be translatated and does not mark the strings that SHOULD be translated. Fixing this is quite some work.

For the xml definitions there is no integrated way to translate these. From your questions and screenshots i assume you simply want to supply copies of these files in different languages, but im afraid this is not a feasible solution and just creates a maintenance nightmare. These files define the data model of wxFB and keeping multiple copies in sync with different language strings in between is just not doable. A possible solution might be to process these files by a script that extracts the translatable strings into a C++ header which then gets processed by standard gettext tools. This approach is used by the XRC system of wxWidgets. But i don't know if these strings can be easily identified, right now only the help strings come into my mind, extracting these should not be so hard. But still, the wxFB code needs also be adjusted to load translations for these strings.

As i said before, localization is quite a huge task and has low priority right now.

[D22699]

I appreciate your kind reply to my question.Most of the problems have been solved.

recent workflow runs，Solved utf8 garbled code.
wxPropertyGrid problem look for WX.

“localization is quite a huge task and has low priority right now.”
We have finished the term translation of XML.

---

Last question
picture3，support Add right-click menu.

It is convenient to obtain the component name and find the Wx document

[sodevel]

I am not sure if i understand you right, do you want an option to open the documentation of a component from e.g. https://docs.wxwidgets.org/ in a webbrowser window? Or just be able to copy the name of the component to the clipboard? If it's the latter, you could copy the name from a source code window.

[D22699]

@jhasse @sodevel

support Add right-click menu.

1/ first

In the right-click menu, add a menu to take the component name. From the perspective of development, adding this function will add several lines of code? You said you could go to the code window? A lot of things, too inconvenient.

We need， copy the name of the component to the clipboard

2/ secondary

Right click Jump to webbrowser

Right click -> (wxPropertyGrid) -> https://docs.wxwidgets.org/3.1.5/overview_propgrid.html