Доступ к OLE-таблице внедрённую во Writer (Embed)

Автор Kadet, 2 ноября 2018, 21:42

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

Kadet

Цитата: economist от  7 ноября 2018, 15:02ThisComponent.LockControllers
ThisComponent.enableAutomaticCalculation(False)
Попробовал. Сходу:
ЦитироватьСвойство или метод не найдены: enableAutomaticCalculation
Пока не разбирался. Может и обойду.

kompilainenn

Цитата: Kadet от  7 ноября 2018, 15:12Однако с английским беда (только с гугл-переводом)
мы так все пишем в баг-зиллу, не парься

Цитата: Kadet от  7 ноября 2018, 15:12Однако - может и получится.
и получится обязательно, я тя уверяю
Поддержать разработчиков LibreOffice можно тут, а наш форум вот тут


economist

Цитата: Kadet от  7 ноября 2018, 15:20Попробовал. Сходу:
Цитата:
Свойство или метод не найдены: 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.     
Руб. за сто, что Питоньяк
Любит водку и коньяк!
Потому что мне, без оных, -
Не понять его никак...

Kadet

Спасибо за рекомендации. Да, прорисовка и "красота" много времени занимает. По большому счёту сами запросы не сильно тормозят. Я пробовал их запускать без красоты в стандартных таблицах Base. Они выводятся мгновенно. А вот сама прорисовка тормозит сильно.
Попробовал эти же запросы реализовать в Calc - существенно быстрей. Причём с форматированием и пр. "красотой". В общем удовлетворяет. Но формируется calc отдельно причём не могу добиться фонового режима, чтобы потом вложить во фрейм формы Base.
Цитата: economist от  8 ноября 2018, 06:47Этот же запрос, запущенный макросом StarBasic, но находящийся во встроенном в LO Python py-скрипте - выполняется за 1 секунду. И это преимущество есть и на 1-м, и на 101 запуске, и с индексами, и без. Причина проста - Python использует свою библиотеку, написанную на языке С вместо ODBC-драйвера, он лучше работает с памятью и типами. Если работать с другим базами - FireBird, PostgreSQL, MySQL - время будет уже 3 секунды, но все равно быстрее "голого" StarBasic.
Заманчиво, но видимо этот вопрос останется для версий 2.0 или 3.0 ибо с Питоном ещё не знаком.

Kadet

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

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