....................
> Да, понятно, что теоретически всё это можно
> реализовать с помощью режима плагинов. Но так
> подгружаемые модули не будут занимать оперативную
> память, выполняясь только при вызове
> соответствующего пункта меню. Да и сам процесс
> программирования должен упроститься. У меня вот,
> например, Каталогизатор виснет уже в процессе
> начальной загрузки, если я пропишу в файле
> конфигурации одну из своих DLL-ек. А при загрузке
> прочих DLL-ек - виснет уже при переходе в
> пользовательский режим (хотя в моем собственном
> АРМе пользовательские функции из них выполняются
> нормально). А некоторые свои модули мне не удалось
> загрузить даже из своего АРМа. В общем, ненадежный
> какой-то этот режим...
DLL плагинов НЕ ГРУЗЯТСЯ до тех пор, пока не будет вызван соответствующий режим. Поэтому мне непонятны Ваши проблемы...

Цитата:

Alio
DLL плагинов НЕ ГРУЗЯТСЯ до тех пор, пока не будет вызван соответствующий режим. Поэтому мне непонятны Ваши проблемы...

Отправил Вам на почту сообщение с подробным пояснением (тема "Плагины для АРМ Каталогизатор и "АльтерВвод""). Хотел приложить к нему файл, но что-то почтовый сервер не пропускает. Поэтому выкладываю здесь. Если не сложно, попробуйте у себя, как работают эти DLL-плагины в Каталогизаторе и моем альтернативном клиенте (который, в общем, и создавался специально для запуска плагинов Ирбиса) - дело в том, что они то работают, то нет в зависимости от конкретной конфигурации и каких-то непонятных мне факторов. Надеюсь, прояснение этого способствует дальнейшему развитию системы Ирбис64 (насколько я понимаю, кроме меня мало кто из пользователей вообще пользуется этим режимом, поэтому и проблем не возникало).

АРМ Администратор-клиент (ИРБИС64)

Обеспечена возможность выполнения ПАКЕТНЫХ заданий - появился новый режим в меню СЕРВИС Главного меню ВЫПОЛНИТЬ ПАКЕТНОЕ ЗАДАНИЕ

Администратор-клиент поддерживает пакетные команды серверного Администратора (с некоторыми исключениями) и кроме того поддерживает новые (дополнительные) команды, такие как:
SEARCH - поиск
PRINT - печать
STAT - статистика
STATF - стат.формы

Полный список пакетных команд содержится в прикрепленном файле.

Правила написания пакетных заданий для Администратора-клиент полностью совпадают с правилами написания пакетных заданий для серверного Администратора.

В связи с пакетными заданиями в INI-файл АРМа Администратор (irbisa.ini) в секции [MAIN] введены следующие параметры:
CLIENT_WORKDIR=c:\irbiswrk\
RecUpdif=
PftOpt=PFTw_H.OPT
MAXBRIEFPORTION=3
MailHost=mail.gpntb.ru
MailPort=
MailFrom=ГПНТБ России
MailFromAdress=alio@gpntb.ru
MailUser=
MailPassword=
DBNFLC=
MAXBRIEFPORTION=3
XMLTAGPREFIX_IND=IND.
XMLTAGPREFIX_FIELD=FIELD.
XMLTAGPREFIX_SUBFIELD=SUBFIELD.
XMLTAGRECORD=
XMLTAGTOPLEVEL=RECORDS
XMLTAGSPACEREPLACE=_
BARCODEHEIGHT=
BARCODETYPE=
AutoinFile=autoin.gbl

которые аналогичны одноименным параметрам для АРМа Каталогизатор.

Для обеспечения запуска АРМа Администратор-клиент через Планировщик заданий Windows таким образом, чтобы АВТОМАТИЧЕСКИ начиналось выполнение определенного пакетного задания, введены новые параметры для клиентского INI-файла (cirbisa.ini - т.е. того INI-файла, который находится на КЛИЕНТСКОЙ стороне) в секции [MAIN]:

BATCHFILE=<путь и имя файла с пакетным заданием>
USERNAME=
USERPASSWORD=

В этом случае в планировщике заданий Windows запуск АРМа Администратор-клиент надо задавать в виде командной строки:

cirbisa_unicode.exe cirbisa_auto.ini

где cirbisa_auto.ini - это специальный клиентский INI-файл АРМа Администратор-клиент, в котором содержатся дополнительные параметры - BATCHFILE, USERNAME, USERPASSWORD.

Следует отметить (для продвинутых администраторов), что предлагаемый список пакетных команд для АРМа Администратор-клиент превращает его по функциональности в ПАКЕТЫЙ АРМ Каталогизатор.

Александр Иосифович! Вот чего не хватает во всем этом счастье, так это опции SEARCH в серверном Администраторе. Большие массивы через сервис гонять, хотя и не часто, но приходится и это очень долго и неудобно

Иркутская ОГУНБ
ИРБИС64.21Турбо
WebИРБИС-PHP

АРМ Читатель, АРМ Каталогизатор, Web-шлюз (ИРБИС64)

Обеспечена возможность применения механизма МОРФОЛОГИИ при поиске по КЛЮЧЕВЫМ СЛОВАМ (не путать с ПОЛНОТЕКСТОВЫМ поиском)

В INI-файлы АРМов Читатель и Каталогизатор (irbisr.ini и rbisc.ini) в секции [SEARCH] введен новый параметр, который разрешает/запрещает применение этого механизма (по умолчанию - разрешает)
MORPHOLOGY=1

В АРМах Читатель и Каталогизатор механизм МОРФОЛОГИИ включается при поиске по КЛЮЧЕВЫМ СЛОВАМ и ОТКЛЮЧЕНИИ опции УСЕЧЕНИЕ (т.е. когда переключатель УСЕЧЕНИЕ установлен в положение НЕТ)

Соответствующее дополнение вносится в язык запросов ИРБИС (который применяется в пакетных заданиях и при создании пользовательских приложений):
для того чтобы указать для поискового термина применение механизма морфологии в поисковом выражении его (термин) необходимо ограничить справа символом '@'
(разумеется, в АРМах ИРБИС это делается автоматически)

Большая просьба к разработчикам.

Сделайте, пожалуйста, вариант регистрации читателя,при вызове АРМ Читателя, в том числе только по его идентификатору без его ФИО.

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

Сделать это самостоятельно не представляет собой никакой проблемы...

В общем, чтобы не засорять эту тему, выделил свои пожелания о дальнейшем развитии возможностей, описанных здесь - [irbis.gpntb.ru], в отдельную тему: [irbis.gpntb.ru]. Приглашаю всех обсудить.

>Большая просьба к разработчикам.

>Сделайте, пожалуйста, вариант регистрации читателя,при вызове АРМ >Читателя, в том числе только по его идентификатору без его ФИО.

>Это, разумеется, необходимо для выполнения закона об охране личных >данных. И с некоторых других точек зрения это также безусловно >необходимо.


>Пользователь: Alio (IP-адрес скрыт)
>Дата: 11, September, 2013 07:01

>Сделать это самостоятельно не представляет собой никакой проблемы...

Александр Иосифович, расскажите подробнее, пожалуйста.

Замените в RDR.FST строку

301 0 "RI="v30,/"RI="v10," "v11," "v12/(|RI=|v27/),/"RI="v24

на строку

301 0 "RI="v30,/(|RI=|v27/),/"RI="v24

И создайте словарь заново.

И кроме того, замените в Irbismsg.txt строку

Идентификатор читателя или ФИО полностью

на строку

Идентификатор читателя

Цитата:

Alio
В секцию [CONTEXT] cirbisc.ini добавлены новые параметры

CurTag= метка текущего поля
CurOcc= повторение текущего поля
MARKEDFIELDS=N кол-во отмеченных полей в текущей записи
MARKEDFIELD0= 1-ый отмеченный элемент в формате <метка>_<повторение>
MARKEDFIELD1=
.....
MARKEDFIELDN-1= N-ый отмеченный элемент в формате <метка>_<повторение>

Следует иметь в виду, что параметры MARKEDFIELDn формируются ТОЛЬКО при вызове плагина (при завершении программы они не формируются)

Александр Иосифович, а могу я попросить доработать эту возможность, чтобы параметры MARKEDFIELDn, а также DBN, формировались ещё и при вызове окон "Печать выходных форм" и "Печать текущего", а также при выборе пункта меню "Печать КК" (последнее можно было бы использовать для доработки моей программы для печати карточек, заменяющей старый OLE-сервер Word'а). Тогда в создаваемых форматах в unifor'ах можно было бы использовать функции из пользовательских DLL, в которых отмеченные поля можно считывать из файла cirbisc.ini. А то с имеющимся у меня форматом "Карточка на отдельную статью" приходится предварительно заполнять в оглавлении служебное поле "№ статьи для копирования", указав номер нужной статьи, и сохранять запись перед вызовом табличных форм. Хотелось бы делать это, просто отмечая нужные пункты оглавления галочкой.

Дело в том, что формат - в зависимости от его конструкций и режима работы - может исполняться на клиенте, а может на сервере (в последнем случае, разумеется, cirbisc.ini недоступен). Поэтому Ваша идея не проходит...

Хорошо, а как насчёт идеи с использованием АРМа в качестве сервера автоматизации - [irbis.gpntb.ru]? Можно считать дальнейшим развитием возможности выполнения пакетных заданий - управление работой АРМ Каталогизатор из внешней программы. В принципе, все солидные софтовые пакеты имеют такой режим работы.

Прочтите в этой ветке пост от 27 августа - и обратите внимание на последние строчки...

Я прочитал, но это не совсем то, что я имел в виду. При работе приложения в качестве сервера автоматизации (OLE-сервера) им можно управлять из внешнего приложения. К примеру, библиографический редактор анализирует текст для выделения в нём элементов записи, а потом Каталогизатор (обычный, с GUI, а не пакетный) перехватывает управление и принимает эту запись. Это как бы дальнейшее расширение идеи плагинов.

Полагаю, что Ваше пожелание НЕ БУДЕТ реализовано...

АРМ Администратор-клиент (ИРБИС64)

Обеспечена возможность использовать ИНСТРУМЕНТЫ - а именно:
-Редактор РЛ и справочников
-Редактор INI-файлов и сценариев поиска.

В главном меню появился раздел ИНСТРУМЕНТЫ с двумя соответствующими режимами

АРМ Книговыдача ИРБИС64

Предлагается новая технология ПЕРЕАДРЕСАЦИИ ЗАКАЗА НА ИЗДАНИЕ-АНАЛОГ. Технология реализуется с помощью соответствующего режима в главном меню и инструментальной кнопки в области ПОЛНОГО ОПИСАНИЯ ЗАКАЗА (см. на прикрепленном рисунке кнопку в красном кружке)

Суть предлагаемой технологии заключается в следующем:
Читатель сформировал заказ на выдачу некоторого издания, но по каким-либо причинам (напрмер, нет свободных экземпляров) выдать его нельзя, но вместо него можно выдать АНАЛОГИЧНОЕ издание (например, тот же учебник физики, но другого года издания) - предлагаемая технология и предназначена для реализации такой возможности.

Действует эта технология следующим образом:
При нажатии соответствующей кнопки (или вызове соответствующего режима) возникает список изданий, которые являются АНАЛОГАМИ издания, заказанного по ТЕКУЩЕМУ заказу (т.е представленному в окне полного описания заказа). В случае выбора аналогичного издания происходит ПЕРЕАДРЕСАЦИЯ заказа (т.е его корректировка), после чего его можно выполнять.
Поиск АНАЛОГОВ происходит на основе специального формата, имя которого определяется параметром в секции [MAIN] INI-файла АРМа Книговыдача
ANALOGPFT
По умолчанию используется формат REL_CONTENT.PFT - тот формат, который используется для поиска СВЯЗАННЫХ документов в АРМах Читатель и Каталогизатор
Пользователю предоставляется возможность создавать/корректировать этот формат по собственному усмотрению.

Необходимо отметить, что АНАЛОГИ ищутся в ТОЙ ЖЕ БД электронного каталога, в которой находится исходное издание.

ИРБИС64

Обновлена документация - ОБЩЕЕ ОПИСАНИЕ СИСТЕМЫ ИРБИС.
Добавлены все новые решения до версии 2013.1 включительно.

Можно попросить небольшую доработку? Собственно, я уже упоминал о ней. Если команды форматирования всё равно не всегда будут срабатывать, если и учитывать в них параметры MARKEDFIELDn - то ладно, Бог с ним. Но мне хотелось, чтобы эти параметры, а также DBN, записывались в файл cirbisc.ini, кроме момента вызова внешнего плагина, ещё и при вызове пункта меню "Печать КК" - по крайней мере, если KKKOLEpriz=0, а параметру KKKPrintProg присвоен путь к внешней программе для обработки записи - ведь последняя в своём роде тоже плагин. Хотелось бы доработать с учётом этих возможностей собственную подпрограмму для печати карточек, основанную на этом режиме - [irbis.gpntb.ru].

Цитата:

При работе приложения в качестве сервера автоматизации (OLE-сервера) им можно управлять из внешнего приложения. К примеру, библиографический редактор анализирует текст для выделения в нём элементов записи, а потом Каталогизатор (обычный, с GUI, а не пакетный) перехватывает управление и принимает эту запись. Это как бы дальнейшее расширение идеи плагинов.

Цитата:

Alio
Полагаю, что Ваше пожелание НЕ БУДЕТ реализовано...

Александр Иосифович, могу предложить более выполнимое средство реализации взаимодействия Каталогизатора с внешними приложениями. Идея заключается в том, чтобы можно было хранить буферную запись Ирбис в буфере обмена Windows. В текущей реализации Каталогизатора можно просмотреть содержимое буферной записи по полям в виде таблицы, но такое представление не позволяет поместить её целиком в буфер обмена. Такая возможность была бы полезной для восстановления буферной записи после выхода из Каталогизатора при его повторной загрузке, а сама перезагрузка АРМа, кроме очевидных случаев сбоев программы / ОС, может понадобиться также после появления сообщения Каталогизатора "БД недоступна для ввода" (в моей практике это случается при попытке сохранить текущую запись на клиентской машине, если сервер в данный момент был перезагружен).
А главное - внешняя автономная программа (такая, как библиоредактор) тоже может сформировать свою библиографическую запись, которую Каталогизатор должен уметь "подхватить". На мой взгляд, это было бы проще всего реализовать созданием библиографической записи (текущей или буферной) на основе содержимого буфера обмена Windows. Требуется всего-то добавить, например, кнопку "Копировать в буфер обмена" в окно "Буферная запись" (команда меню "Сервис" - "Буферная запись") и, скажем, кнопку "Вставить из буфера обмена" в окно "Вставить из импорт. записи" ("Сервис" - "Вставить из импорт. записи").
Можно, конечно, копировать и считывать содержимое буферной записи и из файла (того же cirbisc.ini), но, мне кажется, то, как я описал - это наиболее простой способ.

А каком виде запись должна находиться в буфере обмена Windows?

В формате ALL - полные данные по полям.

Александр Иосифович, скажите, а сложно ли будет доработать irbis64_client.dll так, что бы в нем появилась возможность отдавать с сервера не только текстовые файлы, но и двоичные? Ведь в АРМах Каталогизатор и Книговыдача от сервера идет передача фото читателя, значит какой-то механизм существует... Или идет преобразование в начале во внутренний двоичный ресурс, а потом обратно?

Сейчас реализовал передачу фотографии от сервера к клиенту с помощью чтения двоичноо ресурса на стороне сервера, представления его в виде кодированного двоичного ресурса и раскодирование его на стороне клиента. Работает, но мне кажется, что могло бы быть как-то изящнее. Возможно я что-то упустил из виду.



Редактировано 1 раз. Последний раз 25.09.2013 17:34 пользователем Gena.

Александр Иосифович, хотелось бы выссказать еще одну идею. Возможно она покажется слишком дерзкой, но все же... Можно ли хотяб ы теоретически переделать систему словарей в Ирбисе так, что бы словари формировались не в виде одного файла, а в виде отдельного файла на каждый преффикс. Это сразу же ускорило бы вопросы контроля, актуализации и создания словарей заново. Сейчас за счт многопоточного отбора уменьшилось время на создание словаря, но сортировка все равно происходит в рамках одного потока. А это опять таки узкое место. Опять же, это было бы близко к идеи с использованием файлов IFS. Сейчас использование этих файлов снимает необходимость форматера отрабатывать всю таблицу отбора на записи, выбирая только те поля, которые изменились. Но при этом все равно в какой-то момент времени ВЕСЬ файл словаря блокируется на запись. А если бы для каждого преффикса инверсии существовал бы отдельный файл, то блокировался только он, а в другие файлы-словари в это же время могли бы писать другие пользователи. Это может быть актуально только для очень больших баз, потому скорее всего не заинтересует относительно некрупные библиотеки.

Gena написал(а):
-------------------------------------------------------
> Александр Иосифович, скажите, а сложно ли будет
> доработать irbis64_client.dll так, что бы в нем
> появилась возможность отдавать с сервера не только
> текстовые файлы, но и двоичные? Ведь в АРМах
> Каталогизатор и Книговыдача от сервера идет
> передача фото читателя, значит какой-то механизм
> существует... Или идет преобразование в начале во
> внутренний двоичный ресурс, а потом обратно?
>
> Сейчас реализовал передачу фотографии от сервера к
> клиенту с помощью чтения двоичноо ресурса на
> стороне сервера, представления его в виде
> кодированного двоичного ресурса и раскодирование
> его на стороне клиента. Работает, но мне кажется,
> что могло бы быть как-то изящнее. Возможно я
> что-то упустил из виду.
А чем не устраивает функция
function IC_getbinaryresourse(Apath: integer; Adbn,Afilename: Pchar; var Abuffer: PBuffer): integer; stdcall;

Gena написал(а):
-------------------------------------------------------
> Александр Иосифович, хотелось бы выссказать еще
> одну идею. Возможно она покажется слишком дерзкой,
> но все же... Можно ли хотяб ы теоретически
> переделать систему словарей в Ирбисе так, что бы
> словари формировались не в виде одного файла, а в
> виде отдельного файла на каждый преффикс. Это
> сразу же ускорило бы вопросы контроля,
> актуализации и создания словарей заново. Сейчас за
> счт многопоточного отбора уменьшилось время на
> создание словаря, но сортировка все равно
> происходит в рамках одного потока. А это опять
> таки узкое место. Опять же, это было бы близко к
> идеи с использованием файлов IFS. Сейчас
> использование этих файлов снимает необходимость
> форматера отрабатывать всю таблицу отбора на
> записи, выбирая только те поля, которые
> изменились. Но при этом все равно в какой-то
> момент времени ВЕСЬ файл словаря блокируется на
> запись. А если бы для каждого преффикса инверсии
> существовал бы отдельный файл, то блокировался
> только он, а в другие файлы-словари в это же время
> могли бы писать другие пользователи. Это может
> быть актуально только для очень больших баз,
> потому скорее всего не заинтересует относительно
> некрупные библиотеки.
Что-то подобное будет в версии 2014.1...

Ой, Александр Иосифович, стыдно, пропустил я ее в документации. Большое спасибо.

Буду с нетерпением ждать версии 2014. Очень интересно дальнейшее развитие этого вопроса

Предложение: для авторов добавить дополнительное поле - транслитированная фамилия. Актуально для увеличения точек доступа. Поле разночтения фамилии недостаточно.
Также добавить поле для рефератов на разных языках.
Использовать поле 331 невозможно. Так как отдельный абзац книжной аннотации заносится в отдельное повторение поля.
Тогда можно будет сформировать отдельный словарь для конкретного языка.



Редактировано 2 раз. Последний раз 27.09.2013 00:10 пользователем woodyfon.