Repro.

This error occurs when calling the conversion functions to the Integral type CByte, CInt, CLng in the case when the argument of the String type cannot be converted to a number.

[1], 5.5.1.2.4 Let-coercion to and from String.
Destination Declared Type: Any numeric type.
"If the <regional-number-string> could not be interpreted as a number or currency value, runtime error 13 (Type mismatch) is raised. If the value could be interpreted as a number, but was out of the range of the destination type, runtime error 6 (Overflow) is raised"

This applies to both explicit and implicit conversions.

In my opinion, the fix should also apply to the "Option Compatible" mode.

[1]. [MS-VBAL] - v20240521. VBA Language Specification.
Copyright © 2024 Microsoft Corporation. Release: May 21, 2024.
https://learn.microsoft.com/en-us/openspecs/microsoft_general_purpose_programming_languages/ms-vbal/d5418146-0bd2-45eb-9c7a-fd9502722c74

Code pointer: calls to ImpScan in ImpGet* functions (see e.g. basic/source/sbx/sbxint.cxx, basic/source/sbx/sbxlng.cxx). When ImpScan returns an error, in VBA compatibility mode, we need to set the error.

(In reply to Vladimir Sokolinskiy from comment #1)
> Repro.
> 
> This error occurs when calling the conversion functions to the Integral type
> CByte, CInt, CLng in the case when the argument of the String type cannot be
> converted to a number.
> 
> [1], 5.5.1.2.4 Let-coercion to and from String.
> Destination Declared Type: Any numeric type.
> "If the <regional-number-string> could not be interpreted as a number or
> currency value, runtime error 13 (Type mismatch) is raised. If the value
> could be interpreted as a number, but was out of the range of the
> destination type, runtime error 6 (Overflow) is raised"
> 
> This applies to both explicit and implicit conversions.
> 
> In my opinion, the fix should also apply to the "Option Compatible" mode.
> 
> [1]. [MS-VBAL] - v20240521. VBA Language Specification.
> Copyright © 2024 Microsoft Corporation. Release: May 21, 2024.
> https://learn.microsoft.com/en-us/openspecs/
> microsoft_general_purpose_programming_languages/ms-vbal/d5418146-0bd2-45eb-
> 9c7a-fd9502722c74 https://timecalculators.io/

The information you provided is really helpful. I have a few more comments. We can implement a type checking function (e.g. IsNumeric) to determine if the string can be converted to a number. If not, we will get a Type Mismatch error like in VBA.

This can be done by extending the error handler class in basic/source/sbx/sbxint.cxx and basic/source/sbx/sbxlng.cxx to check the value before assigning.

When a conversion error is detected, we need to make sure that the code returns the corresponding error code (Runtime Error 13 - Type Mismatch). This will make it easier for programmers to identify the source of the problem in their code.

I believe that the "Option Compatible" mode should also be fixed. Both explicit and implicit conversions are covered by this. https://learn.microsoft.com/en-us/openspecs/microsoft_general_purpose_programming_languages/ms-vbal/d5418146-0bd2-45eb-9c7a-fd9502722c74 https://sprunki-game.io

(In reply to Marc Little from comment #4)
> I believe that the "Option Compatible" mode should also be fixed.

Not convinced. While "Option VBASupport 1" is dedicated to the "behave exactly as VBA does", so the bug naturally belongs to that mode - "Option Compatible" mode is a very special; it is not "follow VBA in all aspects", it's a curious mix. We may discuss if this change needs (or not) to be in "Option Compatible" mode - but that should be in a separate bug.