Menu
▾
▴
#1454 Regression somewhere after rev13411 wxSmith wxSpinCtrlDouble
Currently I m testing a build based on rev 13342. The last code I used was rev13411
In Projects using wxSmith for GUI that have wxSpinCtrlDouble I got all sort of Asserts when trying to open the Dialog/frame/panel in he "Ressources" tab.
The asserts are caused by the wxSpinCtrlDouble::Incremtent member which is set to 0. The value before was 0.01.
When trying to change the value the field would not store a value with decimal point. That is the cause of the change, becuase when the original data was 0.01 and the property dialog gets initialized with that data to a field that expects integer, its changed to 0.
I checked with the 13411 build and there the field accepted a decimal value of 0.01. So I would expect the issue has been introduced since.
How to reproduce:
* Create a wxSmith wxDialog
* Add a SpinDouble control. The Initial increment value is 0.01.
* Set the inrememnt value to 0.02
* Observe that the value is changed to 0.
I see this in a Linux Ubunut 22.04 environment on a Trunk compiled with wx3.0.5. Please confirm if ou see the same in Windows and on other environments.
Which is the decimal separator in your locale?
The system uses ','. The other property fields work fine using ','. I tried using '.' as well, but it was not accepted in neither field.
I cannot reproduce, neither on Mint with wx3.0.5 nor on MSW with wx3.2.4. Locale on both systems uses comma as decimal separator.
I have commited now a change, but it just fixes the default increment value so it matches the value given in the constructor (0.01 vs 1).
Thanks for looking into this. I tried to find the right place in the code which is called when the Edit control of that line is executed, but the wxSmith stuff is highly dynamic and I would not figure it out and gave up after a few hours.
If you happen to know where I can place a breakpoint I can try to debug into it.
btw: if you have a good overview of wxSmith you might help with another thing. In tickets/1437 I added a context menu for wxSmith that makes working with it a lot more fun and it works fine. Its currently under review. The only thing left is when an item is copied with he standard copy function the Items from the Quick menu are not copied but reset to their default values. I stepped though with the debugger, but the code is rather weird at that point. Would have expected a base class copy ctor and ctor to set the base values, but the code is a lot more complex and I failed to find the right place.
I am thinking to just save those values in my new functions and reapply them afterwards. But this would be a rather bad hack and keep the root issue left in the code. But maybe that behaviour on Copy is intended? If not, does it make sense to open a new ticket for this copy issue?
I looked at this copy behaviour a couple years ago, but I gave up and currently have little free time.
wxSmith is like the Antikythera mechanism, full of small gears that may break just looking at them. The original creator did a very good job, but it is hard to grasp the inner working.
Thats good to know. So I am going to explore some more with extra care.