Menu

#687 wxSmith color names don't get translated

Undefined
invalid
wxSmith (61)
Bug_Report
2022-01-14
2018-05-09
sodev
No

The color names of the wxsColourProperty won't get translated although they use the _() Macro because this gets called before main(). Actually its quite surprising that the code doesn't crash because converting a temporary wxString to a char pointer should point to that deleted object.

Details see here http://forums.codeblocks.org/index.php/topic,22618.0.html

Discussion

<< < 1 2 (Page 2 of 2)
  • sodev

    sodev - 2019-06-07

    The first time a property object gets created the passed in arrays are processed to create an internal wxPGChoices element. All later created objects ignore the arrays and directly use that element.

    I am not a macro expert but keep in mind gettext is not a compiler, just a simple pattern matcher, these wxTRANSLATE("FooBar") items need to appear in literal in the file.

     
  • Teodor Petrov

    Teodor Petrov - 2019-06-07

    The first time a property object gets created the passed in arrays are processed to create an internal wxPGChoices element. All later created objects ignore the arrays and directly use that element.

    This stil doesn't answer my question! What we will loose if we use the dynamic patch?

    I am not a macro expert but keep in mind gettext is not a compiler, just a simple pattern matcher, these wxTRANSLATE("FooBar") items need to appear in literal in the file.

    XMacro is a fancy dynamic system, so the required things would be available in the preprocessed sources.

     
  • Lieven de Cock

    Lieven de Cock - 2019-06-10

    any decision yet, so we can lift the broken wx30 linux boxes.
    Or do we say we drop wx 3.0, and move to wx 3.1.x ?
    Which is indeed a development version, but at this pace of wx releases I am afraid wx 3.2 might come in like 10 years :-(

     
    • Teodor Petrov

      Teodor Petrov - 2019-06-10

      Dropping wx3.0 on linux is impossible. People would have hard time building cb for their distros... BTW we still support wx2.8.

       
  • Lieven de Cock

    Lieven de Cock - 2019-06-11

    ok, will the breaking change then be reverted ?

     
  • sodev

    sodev - 2019-06-11

    This stil doesn't answer my question! What we will loose if we use the dynamic patch?

    I am not sure what answers your question then, so maybe i give a short summary what this is all about? The element in question is a choice-like property that is used in a wxPropertyGrid to display a fixed list of choices. These fixed list of choices is defined in two arrays, one with the labels, one with the values. Each time a property is created these two arrays are copied into an internal data structure.

    In the static approach this internal data structure is created only once and stored as kind of cache, the first time the property is created. Later the internal data structure is simply used directly. In the dynamic approach the internal data structure is created every time the property is created.

    What do we lose? Nothing but a small performance hit. Creating the internal data structure in the static approach is a bit more expensive because the strings need to get translated, in the dynamic approach the strings in the array are already translated, so there it is basically a memcpy operation.

    If you don't care for working translation in < wx31, which was never working before anyway, i would go with the static solution, its a more simple and straight forward implementation that fits better its purpose: a fixed list of items.

     
  • Miguel Gimenez

    Miguel Gimenez - 2019-06-14

    Can anybody check this patch with wx < 3.1.0? I have redefined _ so poedit can still find the strings but there are no side effects.

     
  • Miguel Gimenez

    Miguel Gimenez - 2019-06-14

    The first part can be also

    #if wxCHECK_VERSION(3, 1, 0)
        #define _(s)   s
        static const char* wxsColourLabels[] = {
    #else
        #define _      wxT
        static const wxChar* wxsColourLabels[] = {
    #endif // wxCHECK_VERSION
    
     
  • sodev

    sodev - 2019-06-14

    The side effect is that for the remaining part of the file the _() macro is "broken"

     
  • Miguel Gimenez

    Miguel Gimenez - 2019-06-15

    It is not used anymore. If it were, you can always push and pop the macro.

     
  • Miguel Gimenez

    Miguel Gimenez - 2019-06-19

    I have tested the patch on Ubuntu 19.10 with wx3.0.4 and it works. I can not test wx2.8.12.

    I have added push & pop of the _ macro so it can be used if needed,

     
  • Teodor Petrov

    Teodor Petrov - 2019-06-24

    @Miguel Gimenez Have you checked if this works with clang? It is something coming from MSVC++ and is supported by GCC, but it is not clear if it is available for clang.

     
  • Miguel Gimenez

    Miguel Gimenez - 2019-06-24

    Clang documentation is a mess, but at least I found that Clang 8 has this warning:

    warning: pragma pop_macro could not pop ‘A’, no matching push_macro

    https://releases.llvm.org/8.0.0/tools/clang/docs/DiagnosticsReference.html

     
  • Miguel Gimenez

    Miguel Gimenez - 2019-06-25

    The push_macro is supported at least from Clang 3.1 (tested with an online clang compiler)

    https://wandbox.org/

     
  • Miguel Gimenez

    Miguel Gimenez - 2020-01-27

    Well, this should work without modifying _()

     
  • sodev

    sodev - 2020-01-27

    This looks pretty much like my previous "static" patch that breaks compilation on wx3.0.x

     
  • Miguel Gimenez

    Miguel Gimenez - 2022-01-14
    • status: open --> invalid
     
  • Miguel Gimenez

    Miguel Gimenez - 2022-01-14

    Translation has always worked, it was made in the constructor of wxEnumProperty(). The code has changed in [r12649], but only for compatibility with wxUSE_STL=1.

     

    Related

    Commit: [r12649]

<< < 1 2 (Page 2 of 2)

Log in to post a comment.