I have some questions regarding the handling of the issue 1637. I’ve seen that you released a new version, that fixes that point. It was an actual issue that some end users reported to me. And I fixed this with a workaround as Robin suggested in the past. This issue is now part of what I’ll scrutinize when testing this new wxPython version.
First, I had real difficulty to reproduce this issue. It was only triggered on a limited number of PCs, out of my reach (at the end user side). On this matter, do you know any easy and fast method to configure a Windows system to trigger this issue? This way I could easily test on my own in the developement process, and observe whether the 4.2 version is fixing this point.
I’m taking some time to open a discussion here, because there are some people who complain about the quality, or express doubt about the real effect of your issue fixing. I quote : “It is just the workaround, It doesn’t solve the problem but merely shuffles it around. Please revert.” So I want to understand what are these concerns? What is the actual issue remaining with this fix? Is is about the locale input which can’t be set as the Windows desktop one?
Still, as far as I can see, the fix seems to be exactly what I did to fix this issue (based on what Robin suggested). And to me, it works fine with this modification. I can’t see any issues with my app. But I don’t use date formatting not advanced locale input stuff. So what would be some adverse effects of this change?
By the way, thank you for this new version. One key point for me is the ability to run on Python3.10. I’ve seen many people having a bad time trying to install wxPython on 3.10, and now this is fixed. For these cases, I suggested them to remove 3.10 and stick to 3.9. I feel that we can also benefit a lot from the new wxWidgets 3.2 version.