Разделитель тысячных

[Gustav]

Попробую еще раз.

МОЕ ПОНИМАНИЕ ПРОБЛЕМЫ:

Цитата:

Сообщение от valentino

Возникла проблема преобразования из текстового представления числа в само число, т.е. из "123 456.78" в 123456.78.
...
Текстовое представлене числа изначально в Аксапте формируется с помощью функции strfmt("%1", число).

МОЕ РЕШЕНИЕ ПРОБЛЕМЫ:

Цитата:

Сообщение от Gustav

Функция strFmt возвращает в виде строки ... real-число - с двумя десятичными знаками ... можно оставить в строке только 10 цифровых символов и знак "минус". Далее полученную строку конвертнуть обратно в число ... "обманув" ... и разделитель тысяч, и десятичную точку (запятую):

... и окончательный вариант "обмана" выглядит так (без предыдущего, возможно кого-то пугающего, деления на 100):

static void Job173(Args _args)
{
    real a = 123456.78;
    str  strNumberAfterStrFmt = strFmt('%1', a);
    real b;
    boolean c;
    ;

    b = str2Num(
        strFmt ( '%1e-2',
        strKeep( strNumberAfterStrFmt, '-0123456789')));

    c = a == b;
    box::info(strFmt('%1\n\n%2\n\n%3',
        strFmt('Исходное число: %1', a),
        strFmt('Восстановленное число из строки: %1', b),
        strFmt('Исходное число равно числу из строки?: %1', c)));
}

P.S.
В процессе эксперимента обратил внимание на то, что региональные настройки Аксапта считывает при старте приложения и далее в текущей сессии их не меняет (!) даже при изменении региональных настроек в панели управления. Такое поведение Аксапты отличается, например, от поведения Excel, где при смене локали c Russian на English (United States) наглядно видно, как в ячейке тут же меняются разделители тысяч с пробелов на запятые.

[lev]

Цитата:

Сообщение от Gustav

этот пост был к следующему:
...
2. Я же говорил о ThousandsSeparator, что он тоже может быть ЗАПЯТОЙ (например, это стандартный разделитель у американцев).
...

Неправильно Вас понял, извиняюсь

[Владимир Максимов]

Gustav

С целыми числами будет ошибка. StrFmt() в этом случае не создает дробной части. Получается лишнее деление на 100.

Хотя, я не теряю надежды услышать РЕАЛЬНУЮ постановку задачи от автора темы

[Gustav]

Цитата:

Сообщение от Владимир Максимов

С целыми числами будет ошибка. StrFmt() в этом случае не создает дробной части. Получается лишнее деление на 100.

Это да. Про целые я уже сделал оговорку выше:

Цитата:

Сообщение от Gustav

Если исходное число целое, то его можно по ходу без напряжения превратить в real, сложив с 0. или умножив на 1. (точки важны!) или разделить на 1 (можно без точки):

int a = 1000000;

strFmt('%1', a + 0.) // или
strFmt('%1', a * 1.) // или
strFmt('%1', a / 1 ) // хоть по теории это и самый долгий вариант, 
                     // зато без точки :)

но вроде круг ограничивается real'ами, т.к. упоминается семейство отчетов RLedgerSheet*:

Цитата:

Сообщение от valentino

Речь идет о семействе отчетов RLedgerSheet* которые отображают формочку с ListView, а в нем отображаются цифры преобразованные в строки.

Т.е. real'ные ДЕНЬГИ! ДЕНЬГИ!

P.S.
Ну, впрочем, можно и допилить слегка, правда, в этом случае появляется зависимость еще и от исходного числа, а не только от промежуточной строки (бррр! бред какой-то! ):

    b = str2Num(
            strFmt ( '%1e-%2',
                strKeep( strNumberAfterStrFmt, '-0123456789'),
                typeOf(a) == Types::Real ? 2 : 0
            ));

[Владимир Максимов]

Мы опять упираемся в ПОСТАНОВКУ задачи.

Вот нафига конвертировать в строку, чтобы потом опять конвертировать в число. Причем еще неизвестно где, по непонятным причинам, пока это была строка произошла замена пробела на неразрывный пробел.

Может проще сразу число прочитать?

[Gustav]

Цитата:

Сообщение от Владимир Максимов

Может проще сразу число прочитать?

Я примерно представляю, о чем может идти речь.

Например, об этом: Главная Книга \Запросы \Оборот по счету \Анализ счета. После задания параметров и кнопки ОК выводится форма "Анализ счета", в которой в колонках "Дебит" и "Кредит" как раз суммы в текстовом виде, с которыми мы боремся.

Суммы превращаются в текст в методе insertRow класса RLedgerSheetEngine_AccountReview:

amount = ledgerTransDebit.exists(rowAccount) ? ledgerTransDebit.lookup(rowAccount) : 0;
formListItem = new FormListItem(strRfix(strFmt("%1", amount), amountDictType.displayLength()));
...
amount = ledgerTransCredit.exists(rowAccount) ? ledgerTransCredit.lookup(rowAccount) : 0;
formListItem = new FormListItem(strRfix(strFmt("%1", amount), amountDictType.displayLength()));

где ledgerTransDebit и ledgerTransCredit - мэпы вида map(typeOf(LedgerAccount), typeof(initialBalance)).

Чтобы получить сумму в первозданном виде, например, при щелчке по строке списка нужно будет считать из нее номер счета, выбрать мэп (дебитовый или кредитовый) и получить сумму при помощи map.lookup.

[Владимир Максимов]

Я бы просто записал число "как есть" в соответствующий Item

formListItem.Data(amount);

А потом, также, "как есть" и прочитал бы.

print formListItem.Data();

Ведь требования к отображению данных могут предъявляться самые разные. Например, округлять до тысяч, или отображать название валюты. И что, менять алгоритмы разбора строки?

[valentino]

Цитата:

Сообщение от Владимир Максимов

Мы опять упираемся в ПОСТАНОВКУ задачи.

Владимир, если Вы внимательно будете читать все топики данной темы сначала, то постановка задачи станет Вам ясна.
Gustav абсолютно точно ее понял.
Вообще, я надеялся, что кто-то подскажет почему Аксапта при преобразовании из числа в строку втыкает тысячным разделителем обычный пробел (32) а не знак разделителя из панели управления (160) (я думал где-то есть тайные настройки).
Но, в принципе считаю тему исчерпанной.
Спасибо всем!

[Gustav]

Цитата:

Сообщение от valentino

Вообще, я надеялся, что кто-то подскажет почему Аксапта при преобразовании из числа в строку втыкает тысячным разделителем обычный пробел (32) а не знак разделителя из панели управления (160) (я думал где-то есть тайные настройки).

В процессе шаманских плясок вокруг функции strFmt созрела такая гипотеза. Конечно, не более, чем предположение (исходного кода функции я не видел). Заключается гипотеза в следующем.

Функция strFmt ведёт себя похоже на функции num2str и date2str. Похожесть заключается в числе прочего и в том, что в качестве разделителей (десятичных, тысяч, элементов даты) используются только разделители, "регламентированные" этими двумя функциями. Так разделителем тысяч в функции num2str может быть точка, запятая, ничего (пустая строка) или пробел, который с кодом 32. Поробуйте поставить в региональных настройках в качестве разделителя тысяч, скажем, букву x (икс латинская) - strFmt все равно будет использовать один из 4-х доступных разделителей - не могу сказать с уверенностью, какой именно - для какого "нерегламентированного" символа.

Таким образом, согласно моей гипотезе, нерегламентированный пробел с кодом 160 "неудачно" заменяется на "регламентированный" пробел с кодом 32 - просто как на один из 4-х возможных вариантов, зашитых в функцию, вводя нас в заблуждение. Т.е. проблема существует, но корни, похоже, у нее совсем другие, чем просто "неряшливость" разработчиков функции strFmt.

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