LibO_Calc: регрессии

Автор ape, 17 сентября 2013, 18:06

0 Пользователи и 1 гость просматривают эту тему.

ape

В Багзилле LibO появилось новое сообщение о регрессии в LibO-4.1.2\3 (наверняка, есть и в 4.2.0.0): при форматировании ячейки по образцу происходит удаление данных. Ошибка пока выявлена и подтверждена в Windows OS: https://bugs.freedesktop.org/show_bug.cgi?id=69450

ape

#1
И ещё одна регрессия: https://bugs.freedesktop.org/show_bug.cgi?id=69440
Если нажать [Help], то вылет Офиса. Проверено на функциях: AVERAGEIF, AVERAGEIFS, SUMIFS, COUNTIFS, IFERROR, IFNA, XOR, NUMBERVALUE и SKEWP.

[вложение удалено Администратором]

ape

#2
GETPIVOTDATA - ещё одна регрессия LibO: https://bugs.freedesktop.org/show_bug.cgi?id=69518

[вложение удалено Администратором]

ape

#3
Ещё одна регрессия. № ошибки не помню, но она имеет статус "исправлено". Действительно, исправлено, но не до конца.
1. Открываем прилагаемый файл.
2. Двойным щелчком выделяем в колонке С ячейку, в строке которой D-ячейка содержит "WRONG", например, С39.
3. Нажимаем [F9] и во всплывающем окне видим правильное значение.
4. Пытаемся продолжить работу с электронной таблицей любым способом.
Это сделать возможно только по [Esc]: в других случаях Calc продолжает работу только с выделенной ячейкой, изменяя данные в окне ввода.
5. По исправлению. Изменения (результат пересчёта) в ячейке не сохраняются автоматически, требуя [Enter].

[вложение удалено Администратором]

JohnSUN

Не уверен, что это регрессия... Обнаружилась благодаря этому вопросу.
Бодро перепасовал файл из этого нашего обсуждения - и облом...

MRI уверяет, что теперь атрибут .Date у календаря теперь void, а не привычная структура Day-Month-Year  :(
Владислав Орлов aka JohnSUN
Благодарить-не зазорно.
Подарить благо создателям офиса, нашему ресурсу, мне

ape

Kohei Yoshida о регресии, связанной с импортом новых функций Excel-2010,2013 (12 ноября, англ.)
ЦитироватьEike довёл до моего сведения, что мои недавние изменения в использовании внутреннего API для импорта формул из XLSX сломали дополнительную обработку, которую UNO API делал, чтобы перевести некоторые из новых функций Excel 2010 и 2013. Эти новые функции обычно имеют префикс _xlfn. в XML-потоке, поэтому имя функции, например, BETA.DIST, будет отображаться как "_xlfn.BETA.DIST" в потоке листа, где хранится ячейка с формулой.
Короче говоря, путь, который я предлагал для решения проблемы, - добавить еще один набор имен функций и связать его с языка формул XL_ENGLISH, используемый на данный момент только для импорта XLSX.
Итак, когда вы, ребята, реализовали эти новые функции в Calc , то получили проблемы импорта XLSX. Пожалуйста, взгляните на ресурс RID_STRLIST_FUNCTION_NAMES_ENGLISH_OOXML в formula/source/core/resource/core_resource.src и посмотрите, соответствует ли сохраняемое имя функции тому, что находится в XML потоке.
Надеюсь это восстановит (фиксирует – fixed) старую функциональность UNO анализатора формата, которая была в ScCompiler.