Возможно ли создать многостраничную форму в LO Base

[Kadet]

Давно периодически рою инет в этом направлении, но пока не добился результата.
На сайте Питоньяка нашёл вариант его 3-й книги в немецком переложении. Оказалось она не только переведена, но и дополнена. Там есть описание возможности создания многостраничного диалогового окна со вкладками (TabPage).
Это делается с помощью создания контейнера в котором создаётся модель TabPage (вкладки).

Код Выделить Развернуть

oTabPageContainerModel = oDlgModel.createInstance("com.sun.star.awt.UnoMultiPageModel")
Даже нашёл ЗДЕСЬ обсуждение багов, связанных с работой этого интерфейса.

При создании диалога этот интерфейс работает. Так же он создаётся в Calc (правда развивать эту нему на стал, там и так вкладки).
А вот на Write, Form в Base и т.п. никак его натянуть не могу.
Уж я его и на сам ThisComponent и на Form и на Frame "надевал". Не получилось. Поэкспериментирую ещё с OLE вариантами.

Никто не экспериментировал в этим? Вкладки во Write документах никто не пытался сделать?

[economist]

20 лет назад, когда появились вкладки, а также палитры, roll-up и иные, более компактные "слои" для построения интерфейсов - у пользователей и программистов самых сложных программ - графических, видеомонтажных, музыкальных итд - аж подгорало: казалось вот он, предел мечтаний.

Прошло всего 15 лет и появился flat-подход, одно-оконный интерфейс, material design - которые все эти плюшки предали анафеме. И стали работать лучше, судя по всему. Это я к чему: вкладки (далее табы) - спорный инструмент. Для построения всяких визардов-мастеров - вообще слабо пригодный. Уж лучше динамически перерисовывать весь диалог (а в таком ПО как Calc - использовать листы, как самое простое и логичное). Особенно это касается делового ПО, тут чем проще и менее красиво - тем продуктивнее в работе и написании.

Я бы задачу (создания многоходового мастера) - сейчас в LO Writer/Base/Calc - решал с помощью... встроенного Python и какого-нибудь Tkinter со товарищи. Да, не очень красиво, а-ля XP, но работало в 2007-м и будет работать в 2027. Кстати, всевозможные визарды не должны быть более чем 5-7 ходовыми, это драматически, стократно снижает точность действий пользователя. А вкладки в 2 строки (многослойные) - приводят к учетверению пустых кликов (ссылка была на Corel corp. и Siemens, но после семинара посеял). Уж лучше древовидный контрол (он есть в LO) а-ля Проводник, как бы это "мешковато" ни гляделось.  

Средства построения диалогов на Basic в LO - отдельная, глючная и плохо документированная тема, сложно программировать события, много хардкодинга. Результат - нет красивых приложений на диалогах LO (в MSO они, к слову, есть). Табы это еще более усугубят, имхо.

[Kadet]

economist, конечно, чем проще тем надёжней, не факт, что красивее.

Однако, мне нужно решить конкретную задачу. По сути у меня есть 6 основных форм, с которыми постоянно работают пользователи и соответственно они, желательно, должны быть всё время под рукой... в зоне лёгкого доступа. Переключение по Alt-Tab - геморно, не для любого пользователя удобно... и весьма путано (легко запутаться в куче свёрнутых форм).
Лучше, чем использовать TabPage для этих целей не придумаешь. Если есть, что удобней подскажите.

Я решил эту проблему следующим образом. В одну основную форму внедрил 6 субформ и путём визуализации и скрытия элементов внутри форм о обычных кнопочек - показываю или скрываю элементы той или иной формы. В принципе, это чем-то похоже на переключение TabPage, НО... скрытие и прорисовка элементов идёт медленно и поэтапно. В общем видно как поочерёдно скрываются одни элементы и появляются другие.

В принципе работать можно, да и работаем так, но хотелось бы всё таки ускорить или скрыть сам процесс прорисовки и скрытия. Эту проблему и могут решить TabPage. Поэтому и стараюсь найти способ реализовать их в формах (а не диалогах) Base.

[mikekaganski]

В общем видно как поочерёдно скрываются одни элементы и появляются другие

У Вас используются LockControllers+addActionLock с их последующей отменой, как показано здесь? (вдруг поможет)

[Kadet]

У Вас используются LockControllers+addActionLock с их последующей отменой, как показано здесь? (вдруг поможет)

Посмотрю попозже. Всё равно, спасибо.
У меня используется цикл, который перебирает все элементы субформ и одни скрывает, другие показывает простым SetVisible. Сам цикличный перебор - уже тормоз. Если все элементы тупо прописать - будет быстрей, но намного ли.
А ваше предложение изучу по свободному времени.

[economist]

у меня есть 6 основных форм, с которыми постоянно работают пользователи и соответственно они, желательно, должны быть всё время под рукой... в зоне лёгкого доступа. Переключение по Alt-Tab - геморно,

- когда то решил аналогичное так:

1) т.к. 90% документов открываются в Calc/Excel - один макрос по горячей клавише, скажем Ctrl+й, определяет контекст: в каком документе я запущен? Банально. по содержанию ячеек, путям и именам файлов, имени пользователя итп. Дальше - ветвление: если это прайс - делаем то-то, если ОСВ по складу - другое. Т.е. этот стартовый макрос определяет какой другой макрос вызвать.

2) другой макрос - делает что нужно, и если там нужен диалог - он появляется (но в 80% случаев пары inpotbox-ов достаточно, также можно локальные хотелки/настройки вынести в ini-файл, люди на удивление легко их правят сами, если там немного всего). Таких специфических макросов за 8 лет набралось за две сотни, и пользователи сказали что им это оказалось удобнее всего. А перепробовали мы до этого и мега-расширения со своим GUI и зависимыми диалогами, и 1С-обработку вместо Basic и COM-автоматизацию из EDM-систем (убив а это пару лет и пару млн. руб.) Ctrl+й и макросы в одной read-only сетевой библиотеке макросов оказались проще и удобней людям.

[Kadet]

У Вас используются LockControllers+addActionLock

Изучил вопрос. Нет, я этот метод не использую. В своё время я его исследовал, но пришёл к выводу, что он мне не подходит. Он используется в Calc, а с Calc-ом у меня подобных проблем нет. Там 6 страниц которые легко переключаются макросом. Иной раз таблицы даже заполняются в фоновом режиме (т.е. одна таблица заполняется, пока активна другая). Пусть даже они заполняются не быстро, но это вполне приемлемо. Добавляется некая "живость" самого процесса. Оператор видит - "всё движется, работа делается"...
economist, всё, что вы описываете в принципе уже реализовано. Единая библиотека макросов вынесена на сервер и в ссылочном доступе для каждого. Макросы рулят кому что открывать и какой доступ давать. Всё это есть.

Я, наверно, не совсем понятно объясняю, чего пытаюсь добиться и от чего избавиться.
У меня есть основная форма. В неё встроены 6 субформ. OLE-calc встроен в основную форму и не зависит от всех прочих субформ. А в субформах я формирую элементы фильтрации, при этом для различных видов работ (форм) они различны. Есть конечно схожие, но в общем - различны. Так вот, при переключении с субформы на субформу автоматически переключается лист во встроенном CALC-объекти (и с этим никаких проблем нет), а вот когда начинают прятаться эти фильтры и выводиться новые - начинается "мультипликация". Поочерёдно прежние фильтры прячутся (по одному) и так же поочерёдно новые элементы фильтров начинают появляться. "Озвучу"...   Тых-тых-тых-тых-тых... старые элементы попрятались... потом тых-тых-тых-тых-тых... новые появились. А должно быть ТЫХ... и старых уже нет, а новые уже стоят.
Эта задача вполне решается с помощью вкладок, но... метод в формах не хочет работать.

[mikekaganski]

А что значит "не хочет работать"? говорит, что нет метода? ругается? падает? молча игнорирует?

Опять-таки, сначала нужен минимальный макрос, показывающий проблему (по возможности, с работающим вариантом (Calc?) для сравнения). Возможно, это баг.

[Kadet]

А что значит "не хочет работать"? говорит, что нет метода? ругается? падает? молча игнорирует?

Да, именно так, что говорит, что нет такого метода. Однако, "нет метода" в конкретном объекте и "невозможно вообще" это разные вещи. Возможно я просто не к тому прикручиваю этот метод. Вот, например, методы формы и методы фрейма или DrawPage это разные методы и одни не взаимозаменяемы. Так вот и предполагаю, а вернее надеюсь, что я просто не к тому объекту пытаюсь приложить этот метод.

с работающим вариантом (Calc?)

А вот это стоит пропробовать. Я просто проверял, что при привязке к calc-документу ошибку не выдаёт, но развивать это направление не пробовал. Попробую. Даже интересно, что получится.

[Kadet]

В calc тоже не получается.

[economist]

Kadet - вы выбрали непростой стек технологий, если я правильно вас понял. OLE-объекты Calc, формы с ними, обвязка макросами - это, на мой взгляд, зона в которой просто неминуемы странности.

Сам Питоньяк на каждой пятой странице про формы и OLE пишет что "это написано в документации, но не работает, зато работает другое, но неизвестно когда перестанет работать". OLE так вообще одноразовая технология, максимум для 1-2 правок. И её существование обеспечивает, по сути, Microsoft, который еще не простил движению OSS потерю 25% своей выручки от офисных пакетов (это 10% всей их выручки, миллиарды USD). 

В то же время есть контролы ODT-на формах/ODS-листах LO, которые нэтивно привязываются к базам данных и простым SQL-запросам (пусть БД - именованные диапазоны в Calc). Они все изначально шустро работают, прорисовываются нормально (кроме Basic-диалогов, там у меня всегда творятся чудеса). Может стоит отказаться от OLE?

[Kadet]

Может стоит отказаться от OLE?

Думаю не стоит. Не для того я так долго искал и внедрял эту модель, чтобы потом от неё отказываться. И меня и моих коллег эта модель вполне устраивает. Она вполне себе нормально и успешно уже более полугода работает. Просто я хочу её ещё улучшить.

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

К тому же, я не совсем верно называю свои встроенные calc как OLE-объект. На самом деле это IFrame-объект. В OLE-его, почему-то, внедрили производители LO списке "Вставить объект", вот я по привычке и называю его. Так вот, OLE - это по сути статические объекты, а IFrame - динамические. Именно это их кардинально отличает. Мои встроенные объекты, они как бы даже не встроенные и даже для самой LO никак не связаны с "родителем". И Воспринимаются самой LO как отдельным, вполне самостоятельным объектом. Единственное, что их связывает (родительскую форму и встроенный calc) это то, что calc-документ открывается внутри окна, которое создаётся в родительской форме... не более.
И получается, мы как бы имеем одну форму, одну её открываем, закрываем, а на самом деле по-сути работаем сразу в двух, параллельно. И они друг другу не сильно мешают. Разве что при открытии немного мешают друг другу, но не сильно.
И меня это вполне устраивает. Зачем же от этого отказываться?
И вообще это моё личное ноу-хау. Никто до меня ещё подобного не делал (по крайней мере я таких примеров не находил). И даже производители не предусматривали такой возможности. Вы даже не сможете вставить в форму Base этот встроенный IFrame, потому что производителями прямой такой возможности не предусмотрено. Мало того, они вообще не рассматривали IFrame для внедрения в них calc или write. Они созданы для роликов и гифок.

А вот работа субформ внутри форм меня не устраивает. Т.е. - меня вполне устраивает то, что не предусмотрено создателями, но совсем не устраивает то, что ими предусмотрено.

[Kadet]

В продолжение темы. Нашёл, что в LO есть целый класс TabPage. Ещё, что применяется он не только к диалогам, но и к менюбар, в частности во Write и Calc меню можно настроить в виде вкладок. Пока это для меня лишь повод к размышлению.

Однако хочу спросить у специалистов, как можно понять и использовать ВОТ ЭТО описание класса? В общем я хочу понять и найти к каким объектам LO он может быть применим. То, что он применим к диалогам и к менюбар это я уже знаю. А более?

[mikekaganski]

Никак. Кроме того, он не используется ни для менюбара, ни для диалогов. Вот его использование.

Для диалогов используется SfxTabPage.
Но и это использовать не получится. Использовать можно только то, что доступно через UNO API.

[Kadet]

Табы прикрутить к формам так и не удалось, но свою проблему я решил. Как описывал ранее, проблема была в быстрой (мгновенной) замене набора фильтров одной субформы на набор другой субформы.
Проблему решил следующим методом.
Вставил в форму 6 врезок (TextFrame), по числу субформ. Внедрил в них и привязал к ним элементы соответствующей субформы (Форма1 -> Врезка1).
Вывел все врезки, а соответственно и элементы фильтров, за пределы документа (в позицию -4см по вертикали при высоте врезки 3,5см). Их стало не видно.

Код Выделить Развернуть

oDoc.TextFrames.getByName("Врезка1").VertOrientPosition = -4000
При нажатии соответствующей кнопки нужная врезка отправляется в позицию 0 в рабочее положение и становится видимой.

Код Выделить Развернуть

oDoc.TextFrames.getByName("Врезка1").VertOrientPosition = 0
А все прочие врезки идут за пределы документа, в позицию -4 и становятся невидимыми.

Замена происходит мгновенно и сразу всем блоком фильтров одновременно, без перебора.
В общем то, чего я и пытался добиться от Табов. Теперь, в принципе, они и не нужны.

Ну, примерно так.