Hi Patrik,

We discussed this case with the design team and decided to handle the exception by restricting the overflow behavior of the NumericTextBox for all data types. The end user does not expect the value to overflow when it reaches the maximum value of the bound data type.

To indicate this behavior to the user, we will disable the respective arrow button when the Value matches Min or Max. This will ensure that users are visually informed when they have reached the limit.

1. Are you okay with our decision to restrict the overflow behavior of the NumericTextBox component?
2. Do you have any concerns or issues with this approach?

I look forward to hearing back from you.

Regards,
Tsvetomir
Progress Telerik

Hi Patrik,

I understand your concerns. The reason for this behavior is that in our source code, we first attempt to increment the value and then clamp it to the maximum if needed.

Additionally, we are constantly trying to improve our product, and I would like to gather more information about this specific case with the following questions:

• Can you please give me an example where you use the NumericTextBox bound to a decimal and encounter an OverflowException?
  

• Is there a real-life use case where a NumericTextBox bound to a decimal is configured in this exact manner?
  

• What is the reason the NumericTextBox component is configured like that in your scenario?

• Does the value (decimal.MaxValue) hold specific significance to your clients?

Answering these questions will provide us with better insight into this scenario and help us make a more informed decision.

Regards,
Tsvetomir
Progress Telerik

Hello all,

After a discussion with the dev team regarding potential improvements and recent research on handling decimal overflow, we are planning to maintain the current behavior. The reason is that the existing behavior follows Microsoft's specifications and prevents the potential precision loss associated with silently managing decimal overflow. This ensures our NumericTextBox component maintains accuracy and compatibility with established standards across various platforms and systems.

For further understanding, you can refer to the Microsoft official documentation on floating-point arithmetic overflow, which details this decimal behavior here. Additionally, to see a practical demonstration of decimal overflow, where a standalone decimal (outside of a NumericTextBox component) reaches MaxValue during incrementation and throws an error, please visit this REPL example.

Note

Following the above, we would be interested in seeing examples of real-life cases where the end-user overflows the Numeric input. If anyone has such examples or additional feedback, we would be happy to review and consider them.

Regards,
Tsvetomir
Progress Telerik