Экспорт в Excel - баги при форматировании чисел
Встретилась с двумя проблемами, возможно баги, НО может я какие-нибудь опции просмотрела?
1. Для чисел в frMemo я выставила специальное форматирование с ThousandsSeparator. У меня в системе это пробел (взятый из системного же списка!!!), frMemo предлагает, похоже, этот же пробел. И с ним же! передаёт строчку в Excel.
Вот тут и грабли - в системном списке разделителей (из comboBox в Regional Options/ didit grouping symbol) находится ???"No Break Space" - chr(160).
Мой Excel такое чудо не кушает, а использует для этих целей строго chr(32), не глядя на системные установки
(см. XLApp.International[xlThousandsSeparator,...]).
Смотрится, конечно, всё нормально, НО вот попробуйте к этому "числу" что-нибудь прибавить...
С другими разделителями проблемы (пока?) не обнаруживались :-)
2. Если число не помещается в frMemo и у мемо выставлен "перенос слов", то число, понятное дело, разобётся на несколько строк. Но при экспорте, уже непонятно зачем, этот chr(10) передаётся и экселю посреди кучи цифр. Понятно, в число такая строка не кастится и суммироваться не будет!
2'. И ещё хуже, если "длинное число" влезает в мемо - тогда в Excel вы увидите его в Scientific format - что совсем не похоже на то, что вы передавали! (а если это было не число, а идентификатор?). Думаю,что и неожиданное конвертирование в дату может встретится - это всё формат General!
По поводу 2 и 2' - логичнее было бы при экпорте на всю рабочую область Excel ставить текстовый! формат (чтоб гарантировать себя от эксельных преобразований, и числа в этом формате замечательно живут ) и передавать wrap text когда он в мемо выставлен
(а от chr(10) во всех случаях избавляться - эксель их сам наставит!).
Извините, очень много текста получилось.
Надеюсь на советы и комментарии.
1. Для чисел в frMemo я выставила специальное форматирование с ThousandsSeparator. У меня в системе это пробел (взятый из системного же списка!!!), frMemo предлагает, похоже, этот же пробел. И с ним же! передаёт строчку в Excel.
Вот тут и грабли - в системном списке разделителей (из comboBox в Regional Options/ didit grouping symbol) находится ???"No Break Space" - chr(160).
Мой Excel такое чудо не кушает, а использует для этих целей строго chr(32), не глядя на системные установки
(см. XLApp.International[xlThousandsSeparator,...]).
Смотрится, конечно, всё нормально, НО вот попробуйте к этому "числу" что-нибудь прибавить...
С другими разделителями проблемы (пока?) не обнаруживались :-)
2. Если число не помещается в frMemo и у мемо выставлен "перенос слов", то число, понятное дело, разобётся на несколько строк. Но при экспорте, уже непонятно зачем, этот chr(10) передаётся и экселю посреди кучи цифр. Понятно, в число такая строка не кастится и суммироваться не будет!
2'. И ещё хуже, если "длинное число" влезает в мемо - тогда в Excel вы увидите его в Scientific format - что совсем не похоже на то, что вы передавали! (а если это было не число, а идентификатор?). Думаю,что и неожиданное конвертирование в дату может встретится - это всё формат General!
По поводу 2 и 2' - логичнее было бы при экпорте на всю рабочую область Excel ставить текстовый! формат (чтоб гарантировать себя от эксельных преобразований, и числа в этом формате замечательно живут ) и передавать wrap text когда он в мемо выставлен
(а от chr(10) во всех случаях избавляться - эксель их сам наставит!).
Извините, очень много текста получилось.
Надеюсь на советы и комментарии.
Комментарии
В твоём случае (если ты хочешь в Excel получать цифры, а не строки) нужно сделать отдельный FRF, в котором не будет никаких форматирований и переноса строк.
Других вариантов я не вижу ...
Значит всё-таки баги в фильтрах? (если нет какой-нибудь специальной опции в фильтре или в memo, решающей эту проблему).
Ведь согласитесь, что передавая, например, '111111111111' совсем не хочется получать в результате '1.11111E+11'
И тут уж дело не в моём "парадоксальном" желании передавать в эксель числа(а зачем тогда люди в xls экспортируют, вместо rtf?) ,
тут уж просто строка неправильно передана (в смысле отображена)!
И вот интересно, есть ли способ достучаться до разработчиков TfrOLEExcelExport с предложением внести минимальные исправления:
всего лишь нужно :-)
- перед передачей данных в xl выставлять формат ячейки "Text" вместо "General" (и тогда вы уже не будете вместо строки '11.11.32' получать в ячейке число!!! '11.11.1932'!!!!.
- в CleanReturns убивать не только chr(13), но chr(10) (а в xl выставлять Wrap Text)
- Там же chr(160) заменять на chr(32) - никто этот chr(160) не использует, и "потеря" будет неощутима :-)
Это скорее не баги, а фичи
Значения ячеек передаются в Excel как Variant, поэтому происходит автоматическое приобразование типов и вы видите строку уже в виде числа.
Если бы весь текст передавался бы как текс, то вам помимо "убирания" формата в FR нужно будет устанавливать формат ячейки уже в Excel-е ..
Нет - вы уж там определитесь в каком виде хотите видеть содержимое ячеек
А это означает, что формат представления наших данных мы задаём в FR!
И далее, в контксте TfrOLEExcelExport , мы именно "в этом виде" хотим видеть наши данные в клетках Excel.
И я предлагаю совершенно "бесплатный" способ (в смысле ничего сложного) избавиться от .
Нужно в фильтре перед передачей данных выставить для всей рабочей области формат ячеек Excel в текстовый (одна строчка кода): и после этого ваши идентификаторы никто не будет пытаться конвертировать ни в даты, ни в числа! (Но числа при этом останутся числами! - ведь это NumberFormat)
Сейчас, по умолчанию, остаётся формат General - и это неправильно!. И это баг - потому что с этим форматом может отображаться не тот string, который передаётся.
Безусловно! НО, этого и не надо! Ведь мы уже всё отформатировали как надо!
С пробелом это, конечно, фича экселя. Но её надо знать! Можно конечно потребовать от всех клиентов :-), чтоб они заменили тот неразрывный пробел на обычный. Но, кажется, что в коде это сделать проще. И место для этого есть - уже есть специальная процедура, где данные чистятся от ненужных символов...
Но, на самом деле, у меня уже нет вопросов по этому поводу. Я думала, что эти фичи многих людей раздражают. Тогда бы, действительно, имело смысл "централизованно" вносить поправки в фильтр. Но, похоже, что в моём случае это очень локальный вопрос, и мы решим его локально же.
Спасибо за обсуждение.
С уважением,
Татьяна
Проблема коневертирования длинных чисел (в моем случае банковского БИК, где от Scientific format идет переполнение всего на один разряд
У меня вопрос: разработчики прислушиваются к вопросам своих клиентов? Или не дождавшись отклика, можно лезть в код?.. :-/
Если меня что-то не устраивает в FR, то я беру исходники и правлю код так чтобы у меня всё работало так как мне надо.
До разработчиков, к сожалению, действительно трудно достучаться ...
И если я знаю решение проблемы, причём по моей (неужели ошибочной?) оценке достаточно распространённой, то я пишу об этом на форум, считая, что
1. Кому-то это поможет разобраться со своими проблемами в экспорте репорта;
2. Кто-то может посоветовать мне более интересное (м.б. корректное) решение;
3. Я выступаю как тестор фильтра, и разработчики могут учесть описанные "фичи" (я по-прежнему считаю несанкционированную конвертацию багом).
Как альтернатива - можно писать в св-во Tag что-угодно. В частности и формат переменной, но это все-равно лезть в исходники.
Кроме того - всем не угодишь, к сожалению.
Сейчас мы очень внимательно наблюдаем в том числе и за высказываемыми тут пожеланиями. Постараемся всё это учесть в готовящейся к выходу версии 2.52. Тем более, что даже в этой теме уже предложили варианты решения.
По поводу внесения всех указанных изменений сразу в новую версию:
не факт, что это не нарушит принципов построения и экспорта, к котрому привыкли остальные пользователи (к примеру, то же св-во Tag может у кого-то уже использоваться для других целей).
Примерно такая же "вечная" тема, как "сумма прописью".
Я (раз такая радость), как зачинатель, уточню то, что несколько сбило уважаемого Vano:
Я тут одновременно поднимала два РАЗНЫХ (хотя и связанных) вопроса:
1. Пресечение нежелательного форматирования экселем передаваемых данных.
(Я лично за выставление текстового NumberFormat, и очень против вставки лидирующего апострофа ('))
2. Потенциальна возможность передачи из FR отформатированных строк (представляющих числовые данные) так, чтобы у Excel оставалась возможность интерпретировать их как числа.
Что обнадёживает, то что в большинстве случаев так и происходит! За рядом исключений, как водится :-)
Это вопрос чистки специальных символов. И тут, понятно, могут возникнуть "конфликты интересов".
Но я за замену chr(160) однозначно -"отряд не заметит подмены бойца"!
И удаление chr(10) очень бы хотелось - но тут надо Wrap Text передавать.
И чтоб не создавать тормозов - сразу на всю область!
А вот передача формата переменной через Tag - точно будет большим тормозом.
Призываю всех поскорее :-), пока не вышла 2.52, написать сюда о проблемах, встреченных при экспорте в Excel.
Не в тему Excel-я, но в тему экспорта:
2. А почему бы не давать разработчику фильтра создавать файл.
3. Хотелось бы переменной в отчете(на этапе его разработки в Run-Time) в которую можно положить имя выходного файла, чтобы пользователю при сохранении - по умолчанию предлагалось это имя.
4. Отдельный каталог для сохранения отчетов.
Похоже кроме меня ни один из перечисленных пунктов не нужен
После выхода новой версии, опять придется по старинке - самому подправлять.