LO-7.2

[Kadet]

Спасибо, Михаил, за сделанный Вами патч с исправлением этой проблемы.
Можно попросить Вас проверить работу ваших исправлений на моей дополненной демке (# 148) и в моей базе (Cyanopica4) на запросах:

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

SELECT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" GROUP BY "Заказчик", "ID"  ORDER BY UPPER("Заказчик") ASC

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

SELECT DISTINCT "Заказчик", "ID"  FROM "ЗАКАЗЧИКИ" ORDER BY UPPER("Заказчик") ASC

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

SELECT list("Размер",';') FROM (SELECT DISTINCT "Размер" FROM "РАЗМЕРЫ" WHERE "Кр">0 ORDER BY "Кр" ASC, "R1" ASC, "R2" ASC, "R3" ASC)

Все ли они работают нормально. В 7.1 и в выделенке все они работают без нареканий.

[mikekaganski]

Дело в том, что этот патч не окончательный. Оно, вероятно, будет работать на релизной версии, но на моей отладочной версии даже с патчем вылезает крах на закрытии программы, связанный с отладочным кодом Firebird, который детектирует перезапись контрольного блока - то есть где-то происходит запись за пределами границ.

Видимо, это как-то связано с неверным возвращаемым значением длины строки.

Я пока не знаю, чей это баг. Он явно старый (как, кстати, и все остальные - просто почему-то проявляться у Вас они стали только сейчас). Но блин как много там багов!

Кстати, пока что рекомендую Вам использовать в запросах TRIM:

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

SELECT TRIM("поле") FROM "таблица" GROUP BY "таблица"."поле"

Но да, если в поле записи есть правильные начальные/конечные пробелы, они уничтожатся...

[Kadet]

Хорошо. Спасибо! Попробую.
В Вашем запросе в багзиле я заметил, что Вы делает упор на кириллицу, но моя обновлённая демка (#148) показала, что и в англоязычных полях она тоже проявляется.
Надеюсь Вы это это тоже заметили.

[kompilainenn]

Но блин как много там багов!

Неужели?!

[sokol92]

Перечитал фрагмент данной темы о глобальных переменных.
Думаю, что конечная цель заключается в организации обмена информацией (параметрами) открытыми документами LO как между собой, так и с приложением. Эти параметры могут представлять из себя любой подтип Variant (скалярные переменные, массивы, объекты), который совместим с UNO.
Глобальные переменные (как библиотек приложения, так и документа) для этого не очень подходят.

У нас есть модуль Basic для этого функционала. Если интересно, я могу его выложить на форум в ближайшие дни (отдельной темой).

[Kadet]

Глобальные переменные (как библиотек приложения, так и документа) для этого не очень подходят.

Почему?

[sokol92]

Если Вы поставляете свой программный продукт неопределенному числу пользователей, то Вам постоянно придется расширять список глобальных переменных в библиотеках приложения и отслеживать версии этих библиотек. Крах произойдет, когда число авторов станет больше 1.
Проще использовать именованные параметры. Эти параметры могут относиться как к конкретному открытому документу, так и к приложению. В библиотеке приложения нужен один модуль, который совершенствуется не часто.
Пример заголовка:

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

' lang:ru
' Запись в словарь.
' - key    уникальный ключ. Если запись с данным ключом есть, то она заменяется.
' - value  значение ключа (любой подтип Variant, включая массивы и объекты).
'          Если значение Empty, то ключ удаляется.
' - doc    документ LO, к которому относится параметр. Если не указан или пуст,
'          то информация относится к приложению.
'  
' Формы для задания параметра doc:
' - документ (объект)
' - свойство RuntimeUID (строка или целое число) документа
' - имя (Title) документа (строка). Не должно быть текстовым представлением целого числа.
'   При таком задании предполагается, что нет открытых документов с одинаковыми именами.
'
' В словаре хранится информация отдельно по каждому документу и приложению.
Sub AppGlPut(Byval key as String, Byval value, Optional ByVal doc)

[Kadet]

Почти ничего не понял, ну ладно.
Число авторов>1 вряд ли планируется. Если доберусь до этого уровня буду изобретать варианты. Возможно и Ваше предложение приму.

Рост числа глобальных переменных не пропорционально росту числа потребителей.
Такое наворачивание всех БД в одну - изначально неправильный путь и появился случайно, в спешке.
В дальнейшем всё это будет почищено, из каждой версии удалено всё лишнее, касающееся других версий. Переменных станет в каждой версии в 2-3 раза меньше, и увеличиваться в дальнейшем не будет.

[Kadet]

Лучше подскажите, где можно в документе LO, в стандартной оболочке документа, найти и записать параметры документа, допустим название, версию и т.п.?
Вот, что-то типа как в Calc: : Файл -> Свойства-> Описание.
В Base этого нет. Засада.

[rami]

Найти можно, например здесь, но зачем записывать?

[Kadet]

"/org.openoffice.Setup/Product"

Возможно я ошибаюсь, но Setup/Product это параметры всего LO, установленного на компе.
Я же ищу свойства самого конкретного документа. Причём, вносить данные желательно вручную с сохранением, а не макросом.

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

[Kadet]

Нет, ну конечно можно вытаскивать версии по названию, из URL, Locate или Title, но... думал есть способ попроще. И был удивлён не найдя свойств документа.

[sokol92]

   Схема работы (для всех типов документов).
  Получаем с помощью метода getDocumentProperties свойства документа (интерфейс XDocumentProperties). Атрибуты этого интерфейса примерно соотвествуют встроенным свойствам документа MS Office.
  При необходимости использования пользовательских свойств получаем с помощью метода getUserDefinedProperties объект, поддерживающий сервис PropertyBag.

[Kadet]

Что дадут мне свойства документа, если мне нужна ссылка на сам документ?
К тому же, как я понял, вместо хранения ссылки на документ во временно "живущей" переменной, Вы предлагаете мне хранить и таскать за собой целый массив данных, по-сути, бесполезных для работы, в некоей сохраняемой библиотеке. В чём резон?

Или я ничего не понял.

[sokol92]

Я же ищу свойства самого конкретного документа.

Мы и говорим о свойствах документа.
Если документ открыт, то мы работаем со свойствами, как указано в ответе #162(). Для занесения своей информации можно использовать системные свойства, например Description. Если системных свойств не хватает, то можно создать пользовательские свойства, которые будут сохраняться (как и системные) при сохранении документа.

Если документ закрыт, то можно прочитать его свойства, не открывая документа в интерфейсе LO, например,  с помощью метода loadFromMedium.

Интерактивно можно работать через Меню / Файл / Свойства...

Update. Открыл  свой тестовый документ *.odb для Postgre и запустил MRI. Интерфейс XDocumentPropertiesSupplier поддерживается, а его единственный метод getDocumentProperties - нет. Что-то новое для меня .  Да, базы данных в LO - зазеркалье.