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

[Kadet]

ThisComponent.LockControllers
ThisComponent.enableAutomaticCalculation(False)

Попробовал. Сходу:

Свойство или метод не найдены: enableAutomaticCalculation

Пока не разбирался. Может и обойду.

[kompilainenn]

Однако с английским беда (только с гугл-переводом)

мы так все пишем в баг-зиллу, не парься

Однако - может и получится.

и получится обязательно, я тя уверяю

[Kadet]

Разместил запрос на Bugzilla – Bug 121254.

[economist]

Попробовал. Сходу:
Цитата:
Свойство или метод не найдены: 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.

Этот же запрос, запущенный макросом StarBasic, но находящийся во встроенном в LO Python py-скрипте - выполняется за 1 секунду. И это преимущество есть и на 1-м, и на 101 запуске, и с индексами, и без. Причина проста - Python использует свою библиотеку, написанную на языке С вместо ODBC-драйвера, он лучше работает с памятью и типами. Если работать с другим базами - FireBird, PostgreSQL, MySQL - время будет уже 3 секунды, но все равно быстрее "голого" StarBasic.

Заманчиво, но видимо этот вопрос останется для версий 2.0 или 3.0 ибо с Питоном ещё не знаком.

[Kadet]

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

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