Основы

[pfantom]

Здравствуйте. Методом тыка изучаю данный язык с помощью рекордера и гугла. Подскажите пару вопросов
1) есть где-нибудь список всех uno с описанием и параметрами.
2)способы кроме uno есть выполнения команд
3) что нибудь что может быть полезно.питоньяка немного. У него не очень понятно
Заранее благодарю

или тип такого


https://xmindshare.s3.amazonaws.com/preview/com-sun-star-text-textdocument-eefgg-1241980332028.jpg

[rami]

Методом тыка изучаю данный язык с помощью рекордера...

Учить язык программирования с помощью рекордера, всё равно, что учить китайский язык (или любой) с помощью китайской пишущей машинки

3) что нибудь что может быть полезно.питоньяка немного. У него не очень понятно

Если Питоньяк с его объяснениями и примерами вам не понятен, то что говорить о сухой документации

Учиться основам программирования нужно всем, но не все должны быть программистами.

[pfantom]

Если Питоньяк с его объяснениями и примерами вам не понятен, то что говорить о сухой документации

в основном мне не хватает знаний какие есть операторы и какие к ним параметры. задачи у меня маленькие углубленного не чего не нужнго

[JumboFrame]

> список всех uno
Можешь поставить расширение "MRI", для современной libreoffice лучше брать с гитхаба - иначе ошибка.

[maksvlad]

Можешь поставить расширение "MRI", для современной libreoffice лучше брать с гитхаба - иначе ошибка.

Какую верси с ГитХаба используете?

[JumboFrame]

Какую верси с ГитХаба используете?

Вчерашнюю =)
Вчера просто скопировал целиком репу и запустил mkzip.sh (так кажется скрипт называется, дома смотрел и на Linux. На windows ещё не проверял.)   
под версией  6.0.3  вполне пошло.

[tagezi]

1) есть где-нибудь список всех uno с описанием и параметрами.

Тут всё, а тут документированная выжимка почти на всё.

Питоньяк до сих пор актуален, даже старое русское издание. По интерфейсам у него не много устаревшей инфы, их не очень активно меняют, и часто старые поддерживаются для совместимости достаточно долго. Уточнить можно в Примечаниях к выпускам. По языку он описал почти всё. Там тоже есть небольшие изменения, но не особо существенные.

ЗЫ: Если вы действительно считаете, что Питоньяк очень сложен для чтения, попробуйте почитать тут. Возможно, после этого Питоньяк покажется не таким тяжелым.

[economist]

Учить язык программирования с помощью рекордера, всё равно, что учить китайский язык (или любой) с помощью китайской пишущей машинки

Применительно к LibreOffice и его макрекордеру, захватывающему команды только через Диспетчер - да. Код от него длинный и часто просто нерабочий. Раньше были попытки исправить ситуацию, но потом кто-то догадался просто "вернуть" VBA в LO и острота проблемы уменьшилась.

Сам VBA в MS Excel - прекрасно "изучается" в его же макрорекордере, причем в режиме реального времени: нажал, к примеру, Ctrl+PgUp - в окне рекордера видишь появление строки ActiveSheet.Previous.Activate. Это быстрее документации, потому что трансляция действий в код мгновенна. Я уж молчу про интерактивные действия типа выделения заполненных областей итп, которые сложно описать словами даже по-английски.
 
pfantom, к счастью, большая (сказать точно сложно, от 60 до 80%) объектной модели Excel (и команд VBA) - поддерживаются в LibreOffice, можно писать гибридный код на двух диалектах одновременно. Скорость выполнения такого кода одинакова с нэтивным SB, а вот написание...  Если есть под рукой Excel с рабочим кодом и макрорекордером - бывает в разы быстрее "записать" и скопировать из окна VBA, чем искать нужный пример у Питоньяка. Но без него никак, другая документация и близко не дотягивает по понятности. Этим объясняется низкая популярность OpenOffice|LibreOffice на фоне MSO в бизнесе. На том же VBA до 2000 г. были написаны грандиозные вещи, например банковское ПО (Citicorp, Сбербанк, ЮгБанк - это не бухучет, конечно, а всякого рода скоринги, процессинги итп), сложные расчеты по зарплате на крупных заводах в РФ, бесчисленное множество MDB-проектов для гостиниц, СТО в Европе итд. На StarBasic я такого уровня проектов не встречал, придется, видимо, сделать самому :-)

Во всех книгах Питонтяк упоминает десятки случаев, когда "родной" код (метод) - просто не работает (не делает ничего и не дает ошибки), и это еще больше дает шансов гибридному VBA. Естественно, формат файла для гибрида - только ODS, никаких XLS/XLS?-форматов. Были времена, когда VBA-макросы выполнялись и правились в OpenOffice 3.1-3.2.1 от Инфра прямо в формате XLS, но сейчас этого нет.

Большую роль играет и копипаста (у меня в офисе она достигает 30% кода), например отсюда https://forum.openoffice.org/en/forum/ причем полезные примеры кода разбросаны во всех разделах (и по Basic и по конкретному компоненту - Calc, Base итд). И здесь на Форуме очень много кода, правда файлы-вложения с кодом частенько удаляют, вся надежда на текст. Чтобы максимально активировать режим совместимости Calc с VBA - см. мои примеры в http://forumooo.ru/index.php/topic,6907.0.html

[tagezi]

Скорость выполнения такого кода одинакова с нэтивным SB

А можно увидеть исследование по этому вопросу?
Лично мое мнение, что код на VBA раза в 2-3 медленнее, чем по средствам api. И я лично не вижу в исходном коде, прям вот чтобы это было одно и тоже.
На мой взгляд VBA по сути надстройка над настройкой.. не совсем прямая, но примерно "А если VBA, по давай всё через Ж делать и считать что два равно трём". И мест, где просто заплатка (ничего не делание), типа "А это мы пока не делаем, потому что не придумали как", в VBA навалом. Ссылка на код выше потом есть, можете сами глянуть.

ЗЫ: А остальное даже комментировать в лом. Простите.

[economist]

tagezi - я сравнивал 3 года назад на "классических", то есть самых популярных в моем офисе (думаю и в других) макросо-задачах типа "нормализации документов" - соединения и перебора больших диапазонов ячеек циклом For Each in [namedrange], вычисления значений и вставка формул, простое форматирование типа [A1].Font.Bold=true У меня создалось впечатление что:

1) скорость SB и VBA в SB - сопоставима, никаких 2-3 раза там нет. Хороший макрос и так работает секунды;
2) интеграция VBA сделана на уровне алиасов к родным api-методам или как-то ещё оригинальнее (т.к. быстро);
3) скорость написания самого кода за счет краткости и вдесятеро большего числа примеров в Сети - вырастает в разы;   

То что некоторые методы не работают и в LO заглушки - догадываюсь, потому и указываю 60-80% "совместимости".

Листинг одной и той же программы на чистом SB - в 3-4 раза больше, чем на SB+VBA. Может "методологически неправильно" учить VBA в LO, но как еще один инструмент для решения задач - достойно упоминания. Ведь кто-то же это всё сделал в нём? К тому же наткнуться в реальной жизни на спеца с опытом VBA в Excel можно гораздо чаще, чем на SB. Программы пишут для решения задач, возможно ТС на гибриде будет легче.

Вот где отставание в 3-4 раза точно есть - так это сравнение cо скоростью работы VBA в MS Excel. "Тест" примерно тот же. Но и это терпимое отличие, не тянущее на выкладывание 10 тр за MSO. 

[tagezi]

я сравнивал 3 года назад на "классических"

Меня интересовали исследования, а не имхо.
Есть ли реальные исследования с тестами и выкладками, которые можно прочитать и попробовать? Не сырого языка (потому что он практически не отличается, а грамотно написанных тестовых задач с использованием UNO API?
Если нет, то это всё голословные заявления. Читая исходный код, разница должна быть, и то что в ваших задачах ризницу вы не наблюдаете, это не значит что её нет.

Писать в ЛО можно хоть на JSFuck. И доказывать, что это классный способ упростить разработку, тоже право скриптописателя, который на нём пишет. Но по факту, в настоящее время, StarBasic и UNO API является наиболее читаемой и быстрой  и стабильной вещью. И последняя вещь - это не моё мнение, а мнение сообщества, которое постоянно отвечает на вопросы: "А почему тут, вдруг перестало работать?".

Поддержка VBA разработана для упрощения миграции, а не для того, чтобы на нём писали. Когда начальник говорит, что завтра вдруг все переходим на ЛО, чтобы админы не рвали себе волосы, а спокойно занимались миграцией, переписав к утру самое критичное.

Далее:
Получить регрессию, из-за дополнительного уровня абстракции, на VBA проще.
Получить, неожиданный результат на VBA, из-за другой абстракции документа, тоже намного проще.
Исходя из этого, понять существует ли ошибка в коде макроса или в коде программы, в разы тяжелее, и можно убить намного больше времени на тестирование, чем при написании при помощи UNO API.
Кстати, пару лет назад, у меня была такая проблема, когда макрос на VBA, вдруг перестал общитывать последнюю строку в диапазоне. Реально проще было переписать, чем выискивать проблему (выложить не могу к сожалению).

И я бы на вашем месте задумался: "А вообще, мои макросы выдают корректные результаты?" ... хотя если уже больше трех лет, то да, лучше не задумываться.

И если бы вы не толкали своё имхо, а иногда читали, что пишут люди на этом форуме, которые имеют знание и в VBA и в LibreOffice Basic (далеко не 3 года, а некоторые уже далеко и не 10), вы бы наверное, поняли, почему настойчиво предлагается последний, хотя большинство из них могут при надобности писать, в том числе и на питоне, и на JS, и на с++ все эти "макросы".

ЗЫ: И не верно говорить, что пишешь на VBA или симбиозе. В LO есть только LibreOfice Basic или симбиоз.

[economist]

tagezi - сравнивать скорость отдельных методов, думаю, никому не интересно. А "общую" задачу для макросов в таблицах, описанную в#9 - можем считать таковой? Может ТС нам свою задачу скажет? Тогда я повторю тест и выложу современные результаты.

С регрессией по VBA сам сталкивался, тут полностью согласен, риск есть. Но наш народ изобретателен, большинство просто гоняет для макросов один и тот же portable-пакет, благо платить за них не нужно, да и у админов можно не спрашивать. Макросы - это микро-программы, под локальный интерес с малым сроком службы. Так что обычного пользователя регрессией не напугаешь
К тому же это бывает и в стане конкурентов. В том же Excel - с версии 95 по 2016 были два периода, когда в течение 2-х месяцев 60% макросов вообще не работало. Например в переход 2003->2007 - отвалился метод Activate для листа, вплоть до выхода SP1. И это в бизнесе, в самом популярном приложении https://ru.wikipedia.org/wiki/Microsoft_Excel, где все должно работать 24х7.

Ситуация с VBA в LO мне очень напоминает традиционную критику языка Python. Все ругают змею за долгие бенчмарки, GIL итп, но писать на нём получается гораздо быстрее. Но честно говорить о потраченном на написание кода времени - в среде программистов не принято.

Если же говорить только о скорости, есть ощущение что её искать нужно не в Basic. PyUNO при работе с большими таблицами, к примеру, работает быстрее чем LO Basic. А в ряде случаев еще быстрее работают крохотные openpyxl и т.п. специализированные библиотеки.  

К сожалению, "странности" и страсти по Python в OpenOffice|LibreOffice напоминают вселенский заговор: зачем-то "выпилены" крохотные pip, setuptools, sqlite3, db-api итд - видимо чтобы юзер писал на чистом, но мертвом "питоне", без библиотек и баз данных. И если с отсутствием поддержки Питона в родной IDE еще как-то можно смириться (её нужно писать с нуля, при том что полно бесплатных решений вплоть до Visual Studio Code), то мотивы "вырезки" базовых функций Питона - не ясны. Его просто намеренно искалечили.

А на Форуме нет разработчиков LO по теме VBA в LO? Какие у диалекта перспективы?