Попробовал. Сходу:
Цитата:
Свойство или метод не найдены: enableAutomaticCalculation
Пока не разбирался. Может и обойду.
Это было для Calc. Просто у нас тут в теме многое перемешалось - макрос для Calc, тема про фреймы Word с таблицами.
По тексту макроса из #10, там очень много форматирования строк кодом. Это слабое по скорости место в OpenOffice|LibreOffice. В Calc есть очень быстрые "стили" таблиц. От части "красоты" в виде заливок можно и отказаться (в пользу скорости). Или сделать их на условном форматировании.
Если есть опыт в VBA, то можно форматирование VBA-кодом в коде StarBasic писать более лаконично:
Option VBASupport 1
Option Compatible
Sub TestVBAFormatting()
With [NamedRangeOrA1:B4style]
.Font.Bold=true
.Font.Size=12
.Interior.Color=255 ' красная заливка
End with
End sub
Кроме того, Calc и Writer в данном кейсе могут оказаться вообще лишним звеном, если делать ODT/ODS/PDF отчеты прямо в Base на базе SQL-запроса. Есть целых три рабочих способа - встроенный построитель отчетов, расширения Oracle Report Builder и BRE.
Возможно сам SQL-запрос выполняется долго (индексы?) Вот одно практическое наблюдение:
Запрос к СУБД SQLite через JDBC/ODBC-драйвер на языке StarBasic (подобный #10), использующий выборку 100 тыс. строк из 1 млн. строк, отбор, группировку, функции суммирования итп - выполняется за 6 секунд.
Этот же запрос, запущенный макросом StarBasic, но находящийся во встроенном в LO Python py-скрипте - выполняется за 1 секунду. И это преимущество есть и на 1-м, и на 101 запуске, и с индексами, и без. Причина проста - Python использует свою библиотеку, написанную на языке С вместо ODBC-драйвера, он лучше работает с памятью и типами. Если работать с другим базами - FireBird, PostgreSQL, MySQL - время будет уже 3 секунды, но все равно быстрее "голого" StarBasic.