Locale Tolerant Number Parser

StringToDouble() stops parsing at the first character it does not recognise and returns whatever it managed to read up to that point, with no error signal at all. Feed it "1,234.56" - a completely ordinary US- formatted number - and it returns 1.0, silently discarding everything after the comma. Feed it "1.234,56", the equally ordinary European convention for the same value, and it returns 1.234 (the comma is simply ignored). A pasted broker statement, a CSV column exported by a European copy of Excel, or a number typed into an input box by hand can all produce values a naive parse gets confidently, silently wrong. ParseLocaleNumber() handles both conventions and several common decorations. Currency symbols and letters are stripped, plain and non- breaking spaces used as thousands separators are removed, and accounting- style negative parentheses "(1,234.56)" are recognised and turned into a proper negative number. The genuinely hard part is deciding which of ',' and '.' is the decimal point when only one of them appears in the string. When both appear, the rule is unambiguous: whichever occurs LAST is the decimal separator (this correctly handles both "1,234.56" and "1.234,56"), and the other is removed as a thousands separator. When only one separator character appears, this library uses the digit-run-length heuristic real-world data almost always satisfies: a separator followed by exactly one or two digits to the end of the string is treated as a decimal point ("1234,5" -> 1234.5); a separator followed by three digits, or appearing more than once, is treated as a thousands separator ("1,234" -> 1234, "12,345,678" -> 12345678). That heuristic has one genuine, irreducible ambiguity: a bare "1,234" with no other context could mean either "one thousand two hundred thirty-four" (thousands separator, the more common real-world case, and what this library returns) or "one point two three four" (decimal comma). There is no way to tell which was meant from the string alone - this is stated plainly rather than hidden, and any caller working exclusively with European decimal-comma-no-thousands-separator input should be aware a bare three-digit-tail comma will be read as a thousands separator. Notes and limitations - The bare-comma / bare-dot ambiguity described in FULL DESCRIPTION is genuine and unavoidable from the string alone - "1,234" always resolves to 1234 (thousands separator), never 1.234 (decimal comma), regardless of which convention the original data actually used. - A string with no digits at all ("n/a", "-", "") returns false rather than 0.0, so a caller can distinguish "genuinely zero" from "not a number" - always check the return value, do not rely on the output value alone. - Only a single leading/trailing currency symbol or code is handled by being stripped along with everything else that is not a digit, separator, sign or space; this library does not validate that the symbol matches an expected currency, it simply ignores it. - Scientific notation ("1.5e10") is not recognised - the 'e'/'E' is stripped as decoration along with any other letters, which corrupts that value. This library targets plain decimal amounts, not exponential notation.

Script · MT5 · v1.0 · Free

Tags: Buy/Sell Arrows · MT5 Script · MQL5 Source Code

MQL4 & MQL5 scripts · PolyMaria