sodev

Yes, it is still broken, but the wxWidgets folks made broken code to compile again, just for the sake of compatibility. See the explanation here https://github.com/wxWidgets/wxWidgets/commit/02ffdd16f6664a3b81e24ced192fbeccaa4393ef. So i'm still sure my patch fixes the code, too bad i still don't know what to do that these code locations are getting executed so that i can verfiy that.

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

My wxWidgets builds are always without any compatiblity enabled :o). Most wxWidgets libraries i saw are pretty dead and this library is contained as copy so i didn't check if upstream is still alive. So this is kind of good news for you, not your fault and upstream already fixed it itself, so my patch is kind of obsolete now.

Plugin source_exporter compile fix for wx-master

There you have your technical limit you can enforce ;o)

I'm strongly against this, don't impose artifical limitations without technical reasons. I have a 4K screen, i can easily fit 200 status fields on it which display a small icon, 2 letter code, or whatever. Will i ever have the need to do that? I have no idea. But maybe someone else has ideas, who knows. Does it crash if you add more than max short? Or max int? Place a limit on that then. But otherwise, let the user pick what he wants.

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

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...