Обносление испортило формулы

[mikekaganski]

Когда Вы работаете с числами и строками, первое, что необходимо понять - это что число может быть представлено разными строками, а разные строки, представляющие одно и то же число, могут быть по-разному восприняты в разных случаях. Это связано с богатой историей человечества, письменности, математической записи и других увлекательных вещей. В принципе это всё зависит от локали (то есть от соглашений по представлению данных, принятых в данной местности или в данной ситуации).

Понимание этого приводит нас к понятию текущей локали. Обычно это то, что представляется "обычным/нормальным" простому пользователю Вашей программы: например, использование запятой для разделения дробной части в России. В Basic стандартные преобразования все задуманы использующими именно текущую локаль - то есть все стандартные преобразования должны в России считать дроби отделяющимися запятой.

Однако при программировании имеется множество вещей, которые не должны зависеть от локали. Например, если Вы формируете формулы и будете их писать для Вашей русской локали, с использованием русских названий функций и т.п., то программа не будет работать в других локалях. Поэтому программист должен думать о том, в каком месте программы у него данные в текущей локали, а в каком - должны быть независимы от текущей локали. Это основы, без этого понимания всегда возникают проблемы.

В ЛО был баг, что стандартное преобразование числа в текст всегда использовало "стандартную" локаль en-US, а стандартное преобразование текста в число - текущую локаль. Это было несоответствие документации и дизайну. Это и было исправлено. А для приобразования любого числа в стандартный вид (независимо от локали в строку с использованием точки для разделения целой и дробной частей) - всегда были функции Str и Val. Надо преобразовать строку, введённую пользователем, в число - используем стандартное преобразование (просто присваиваем строку числовой переменной). Надо взять число из базы данных, где числа в стандартной форме - используем Val(s). Надо число показать пользователю - используем стандартное преобразование (например, просто передаём число в MsgBox), что даст привычный для пользователя вид. Надо число засунуть в формулу Calc, где используется стандартный вид - используем Str(n).

Ну и всегда для преобразований с использованием локали (то есть вместо стандартных преобразований) можно было использовать функции CStr/CInt/CDbl/...

То, что Вы полагались на нестандартное, ошибочное поведение в одних местах, и страдали от того же самого в других - это и был баг, который полностью рушил логику  преобразований. Исправление ничего не усложнило. Если бы Вы использовали Str/Val/CStr/CDbl... везде, где данные преобразуются между типами (число-строка), Вы даже не заметили бы ничего.

А использовать replace для того, что Вы делаете - нельзя, потому, например, что в некоторых локалях запятая - это разделитель тысяч.