<kompi>
mikekaganski: посмотри на путь до библиотеки
<kompi>
не от того ли либра на винде спотыкается при установке, что путь длиннее 255 символов?
<mikekaganski>
где ж он длиннее?
<kompi>
а разве нет?
<mikekaganski>
нет
<kompi>
ок, то есть это нормально, что в такую опу прячется файл?
<mikekaganski>
131 символ
<mikekaganski>
нормально
<kompi>
ладно бог с ним
<kompi>
мне просто показалось, что это не очень правильно в принципе, такой путь делать для установленных расширений
<mikekaganski>
Ну, для начала: пользователь устанавливает расширения в свой профиль. Он у тебя в c:\users\YourName\AppData\Roaming\LibreOffice\4\user - и это нормально.
<kompi>
это да
<kompi>
а дальше?
<mikekaganski>
Внутри него путь uno_packages/ - нормально. А внутри распакованное расширение (изначально-то оно в архиве) - в папке cache с подпапками для возможности параллельного хранения нескольких версий на случай необходимости
<kompi>
хм
<kompi>
короче
<kompi>
mikekaganski: ты готов дальше мне забивать моск?
<mikekaganski>
:)
* kompi
вчера почитал таки Питоньяка и понял, какого Х переменная i объявляется с %
<kompi>
это просто INTEGER >_<
<kompi>
сокращенно
<mikekaganski>
да
<kompi>
mikekaganski: вчера мы остановились на том, что все работает, но ни фига не делает, потому что нет объектов
<mikekaganski>
теперь нам нужно, чтобы GetObjectsFromDoc делала какую-то реальную работу и наполняла объектами массив
<kompi>
ну как бы да
<mikekaganski>
и здесь нужно обратить внимание на важное различие между модулями
<kompi>
сначала надо прочекать модуль
<mikekaganski>
Во всех модулях встроенные объекты располагаются на специальных "листах", называемых DrawPage
<mikekaganski>
Но в Calc, Draw и Impress каждый документ содержит несколько таких листов
<mikekaganski>
а в Writer существует только один такой лист
<mikekaganski>
и доступ к этим листам осуществляется по-разному
<mikekaganski>
в Calc-Draw-Impress есть коллекция листов, которую мы перебираем и по одному работаем с отдельными листами
<mikekaganski>
а в writer коллекции нет, а есть доступ сразу к единственному листу
<kompi>
примем за аксиому
<mikekaganski>
На самом деле я думаю это исправить: добавить в writer тоже коллекцию. Ну и пусть она будет с единственным листом, зато можно будет упростить работу из скриптов. Но это пока прожект
<mikekaganski>
поэтому нам нужно иметь возможность по-разному обрабатывать разные типы документов
<kompi>
ты сломаешь существующие макросы тогда
<mikekaganski>
нет
<mikekaganski>
ничего не мешает иметь и прямой доступ к листу, и коллекцию одновременно
<kompi>
ладно, мы отклоняемся
<kompi>
аа
<mikekaganski>
В StarBasic есть базовый механизм работы с UNO-объектами, которыми являются все объекты ЛО, с которыми ты имеешь дело в скрипте
<mikekaganski>
например, oDoc или oDialog - это UNO-объекты
<mikekaganski>
так вот, каждый такой объект реализует какой-то набор интерфейсов, каждый из которых имеет название, и каждый из них предоставляет какие-то функции и свойства
<kompi>
угу
<mikekaganski>
Например, когда ты пишешь что-то наподобие oSel = oDoc.CurrentSelection, ты обращаешься к свойству CurrentSelection интерфейса XSelectionSupplier
<mikekaganski>
И это обращение возможно только из-за того, что oDoc реализует такой интерфейс
<mikekaganski>
по-хорошему стоило бы предварительно проверить, так ли это, но мы знаем, что все объекты-документы ЛО реализуют его, так что мы просто обращаемся к выделению без проверки
<mikekaganski>
А вот доступ к графической странице или к коллекции графических страниц реализуется другими интерфейсами, и их реализацию мы как раз и будем проверять
<mikekaganski>
Итак, начнём с Writer
<mikekaganski>
функция проверки интерфейса - HasUnoInterfaces
<mikekaganski>
и нам нужно будет удостовериться, что документ поддерживает интерфейс "com.sun.star.drawing.XDrawPageSupplier"
<mikekaganski>
Итак: на данный момент GetObjectsFromDoc делает два действия: создаёт пустой массив, и возвращает его в виде результата
<kompi>
погоди
<mikekaganski>
между этими двумя действиями мы вставим проверку
<mikekaganski>
ок
<kompi>
ты же сказал, что все документы имеют drawpage
<mikekaganski>
нет, либо DrawPage, либо коллекцию DrawPages, внутри которой уже будут DrawPage
<kompi>
тогда что означает вышеприведенный интерфейс?
<mikekaganski>
этот интерфейс - это как раз и есть доступ к графической странице
<kompi>
эм
<kompi>
это я понял, я не понял зачем мы его проверяем на наличие
<mikekaganski>
а у других модулей будет "com.sun.star.drawing.XDrawPagesSupplier"
<kompi>
ааа
<mikekaganski>
обрати внимание на Page - Pages
<kompi>
да увидел
<kompi>
то есть это Writer специфичный
<mikekaganski>
Ну, именно у документа - да
<kompi>
ок
<mikekaganski>
дальше?
<kompi>
да
<mikekaganski>
насчёт двух действий в GetObjectsFromDoc - норм?
<kompi>
в каком плане?
<mikekaganski>
вопросов нет?
<kompi>
проверяем наличие интерфейса и создаем массив объектов?
<mikekaganski>
Так вот, после создания пустого массива, но перед его возвратом мы вставим проверку интерфейса и действия в случае, если интерфейс поддерживается
<mikekaganski>
да
<kompi>
да ок
<mikekaganski>
Получатся три дополнительные строки:
<mikekaganski>
If (HasUnoInterfaces(oDoc, "com.sun.star.drawing.XDrawPageSupplier")) Then
<mikekaganski>
Наша последняя функция будет возвращать массив объектов. Поэтому начнём её с создания пустого массива (аналогично GetObjectsFromDoc )
<mikekaganski>
Dim vObjects() As Object
<mikekaganski>
а закончим - опять-таки аналогично - возвратом этого массива: GetObjectsFromDrawPage = vObjects
<kompi>
угу
<mikekaganski>
А вот между ними вставим перебор объектов на графической странице
<mikekaganski>
Мы это будем делать только если там вообще есть объекты
<mikekaganski>
поэтому: If (oDrawPage.Count > 0) Then ... End If
<kompi>
разве может быть графическая страница без объектов?
<mikekaganski>
а почему нет?
<mikekaganski>
вначале так и есть
<mikekaganski>
код, возвращающий графическую страницу, создаёт её при необходимости (пустую)
<kompi>
ок, примем за ксиому №2
<kompi>
далее
<mikekaganski>
Когда мы увидели, что хоть какие-то объекты есть, мы превратим наш массив из пустого (состоящего из НУЛЯ объектов) в массив из стольких объектов, сколько на странице
<mikekaganski>
(сами эти объекты пока пустые, но массив уже непустой)
<mikekaganski>
ReDim vObjects(0 To oDrawPage.Count-1)
<kompi>
это где?
<kompi>
в условии?
* kompi
потерял логику
<mikekaganski>
"как только мы увидели, что хоть какие-то объекты есть"
<mikekaganski>
то есть да, если число объектов больше нуля
<mikekaganski>
Правда, тут мы берём не getEmbeddedObject, а Model, но суть не меняется
<mikekaganski>
у этого есть причина. Для наших формул и Model, и EmbeddedObject указывают на одно и то же. Поэтому без разницы, что использовать. А вот когда мы перейдём к кальку сотоварищи, окажется, что там нет EmbeddedObject
<mikekaganski>
так что я тут заранее заменил обращение к EmbeddedObject на совместимую Model
<mikekaganski>
ку?
<kompi>
аа, я тут, все ок
<mikekaganski>
я переспрашиваю, чтобы знать, что всё понятно
<kompi>
мне казалось, что я даю какие-то звуки в ответ=(
<mikekaganski>
строка 5 должна идти после строки 15
<mikekaganski>
мы всё это делаем только внутри ифа, т.е. только если есть объекты
<kompi>
эээ
<mikekaganski>
на самом деле твой код, как ни странно, тоже будет работать, поскольку твой цикл не отработает ни разу, если объектов нет. Но просто такая структура нелогична
<kompi>
это не мой код, я в данном случае - обезьяна
<kompi>
дорасту до уровня Леры, тогда будет мой код
<kompi>
mikekaganski: код такой? если да, то по поводу логики:
<mikekaganski>
всё так, жду коммент
<kompi>
так вот
<kompi>
хм
<kompi>
если объекты вообще есть, то мы начинаем их перебор на предмет соответствия типу "формула" и наполняем ими массив?
<mikekaganski>
нет, не формула
<mikekaganski>
а "встроенный объект"
<kompi>
любой объект?
<mikekaganski>
на предмет формулистости уже проверяет formatting
<mikekaganski>
Тут многослойный пирог
<kompi>
то есть тут мы просто набираем массив объектов, если таковые есть
<mikekaganski>
на странице есть объект - это может быть линия, или круг, или встроенный объект
<kompi>
любых
<kompi>
что делает ReDim?
<kompi>
почему оно без уазания типа?
<mikekaganski>
погодь
<mikekaganski>
если это встроенный объект, то у него внутри есть ссылка на реальный объект
<mikekaganski>
это может быть формула, а может быть рисунок автокада
<kompi>
хм
<kompi>
а если это картинка?
<mikekaganski>
так вот, мы делаем первый уровень фильтрации здесь - проверяем, что объект - это тот самый встроенный объект - и в массив тогда вставляем не его, а реальный объект, который сидит внутри
<mikekaganski>
ну, может оказаться и картинка
<kompi>
встроенная в документ картинка PNG
<mikekaganski>
уже внутри formatting мы проверяем, что реальный объект - это формула
<mikekaganski>
можно и второй уровень сюда перенести на самом деле
<kompi>
'v&
<kompi>
второй - проверка на "формульность"?
<mikekaganski>
да
<kompi>
погоди, насчет "реального объекта"
<mikekaganski>
я разделил уровни сначала, т.к. не был уверен, что первый уровень будет одинаковым для разных модулей
<mikekaganski>
годю
<kompi>
мы же не сам объект пихаем в массив, а только ссылку на него...или как?
<mikekaganski>
Во-первых, Obj1=vObjects(i).getEmbeddedObject неверно, поскольку мы уже получили реальный объект раньше, и в массиве именно он
<mikekaganski>
заменяем его на Obj1=vObjects(i)
<mikekaganski>
Во-вторых, проверка на If Obj1.supportsService("com.sun.star.formula.FormulaProperties") then теперь лишняя, т.к. мы обеспечили это условие для всех непустых объектов ранее
<mikekaganski>
убираем её (и соответственно, строку 37)
<mikekaganski>
в общем-то, теперь всё (ну, если не обращать внимание на форматирование отступов :))
<kompi>
угу
<mikekaganski>
Вот как она выглядит у меня (там старые названия, так что напрямую ты её не сможешь использовать, отправляю просто для посмотреть): https://pastebin.ca/3956385