Celestia
Celestia copied to clipboard
CelestiaProject
[win] Can't paste floating point numbers into the "Julian Date" field
Describe the bug Apparently 1.6.2 still has bugs. In both 1.6.1 and 1.6.2, I can't type a decimal point in the "Julian Date" field of the "Set Simulation Time" window. In 1.6.1 I'm still able to paste in a number with a decimal point, but when I try to do that in 1.6.2 I get the message "Unacceptable Character. You can only type a number here."
This bug does not exist in 1.7.0, either the Qt or Windows native version. @LukeCEL is unable to reproduce this on Mac.
To Reproduce Steps to reproduce the behavior:
- Go to "Time" menu
- Click on "Set Time"
- Copy and paste a floating point number (e.g.
2451330.5069) into the "Julian Date" field - See error message
Expected behavior The number is pasted into the "Julian Date" field.
Desktop (please complete the following information):
- OS: Windows 10
- Version: 1.6.2
It's really curious, git diff showed no defference in wintime.cpp between 1.6.x and master. But I only briefly looked at it. Also I dont have Windows.
@SevenSpheres what is your locale? I cannot enter a point, but I can paste without any errors.
okay. maybe the different behavior because you use windoze, while i checked using wine.
https://docs.microsoft.com/en-us/windows/win32/controls/edit-control-styles says:
ES_NUMBER | Allows only digits to be entered into the edit control. Note that, even with this set, it is still possible to paste non-digits into the edit control. To change this style after the control has been created, use SetWindowLong. To translate text that was entered into the edit control to an integer value, use the GetDlgItemInt function. To set the text of the edit control to the string representation of a specified integer, use the SetDlgItemInt function.
To fix this we need to use custom controls. But as we don't have any windoze dev, we doubt this will be ever fixed.
But as we don't have any windoze dev, we doubt this will be ever fixed.
Okay, it can probably be closed then, since it's not that big an issue and only affects 1.6.2.
Okay, it can probably be closed then, since it's not that big an issue and only affects 1.6.2.
Closing because of this, since there's now a final release of 1.6.2 (except for data updates, which can hopefully be added later as a 1.6.2.1 update)
This issue seems to be present in 1.7.0 with the native Windows frontend, although according to my original post it wasn't in 2020.