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

Доработка вдогонку 2013.1, касающаяся ПАКЕТНЫХ ЗАДАНИЙ.
Вводится новый параметр (irbisa.ini [MAIN])
BATCHMNU=
который определяет справочник со списком доступных пакетных заданий.
В справочнике указывается ИМЯ пакетного задания (без расширения - подразумевается IBF) и его описание (назначение). Значение параметра по умолчанию - batch.mnu
Справочник (также как и собственно пакетные задания) должен находиться в папке БД или в папке DEPOSIT.
В случае использования (наличия) такого справочника пользователю предлагается возможность выбирать пакетное задание из списка (при этом сохраняется возможность выбирать пакетное задание через стандартный ОБЗОР).

Александр Иосифович, напоминаю свою просьбу, озвученную на Либкоме.Параметрировать возможность выбора интерфейса для РЛ подполей.

АРМ Каталогизатор ИРБИС64

Обеспечена возможность выполнения ПАКЕТНЫХ ЗАДАНИЙ (по аналогии с АРМом Администратор-клиент - см. релиз 2013.1)
В связи с этим в раздел СЕРВИС главного меню введен режим ВЫПОЛНИТЬ ПАКЕТНОЕ ЗАДАНИЕ
Поддерживаются только те команды пакетных заданий, которые связаны с функционалом АРМа Каталогизатор, а именно:
OPENDB
SEARCH
IMPORTDB
EXPORTDB
COPYDB
GLOBAL
PRINT
STAT
STATF
OPERANDSEP
EXIT
SILENCE

Подробное описание команд пакетного задания см. в релизе 2013.1

В INI-файл (irbisc.ini) в секцию [MAIN] введен новый параметр
BATCHMNU=
определяющий справочник со списком пакетных заданий, доступных каталогизатору. По умолчанию - batch.mnu (Должен находиться в папке БД или в DEPOSIT)
Также введен параметр в секции [MAIN]
BATCHABLE=
который определяет доступность (значение 1 - по умолчанию) данного режима.

Важное дополнение.
Для пакетных заданий, исполняемых в АРМе Каталогизатор, предусмотрена возможность использовать ПЕРЕМЕННЫЕ ПАРАМЕТРЫ - которые задаются перед началом выполнения пакетного задания через опросный РЛ подполей и передаются в собственно пакетное задание.
Имя опросного РЛ подполей задается в первой строке пакетного задания (с расширением). Значения разделителей подполей такого РЛ не имеют значения - имеет значение только КОЛИЧЕСТВО и ПОРЯДОК элементов (переменных параметров) в нем. Задаваеме переменные параметры используются в пакетном задании в виде конструкций:
%N
где N - порядковый номер параметра (подполя) в РЛ подполей.
Конструкции %N могут использоваться не только в собственно тексте пакетного задания, но и:
- в тексте глобальной корректировки (файл *.gbl), которая выполняется с помощью команды GLOBAL пакетного задания;
- в тексте формата (файл *.pft), который выполняется с помощью команды PRINT пакетного задания (только для СПИСОЧНОЙ печати);
- в тексте задания для стат.формы (файл *.stf), которое выполняется с помощью команды STATF пакетного задания.

Использование переменных параметров для пакетных заданий открывает пользователям широкие возможности по созданию ТИПОВЫХ ПАКЕТНЫХ ТЕХНОЛОГИЙ, т.е. таких последовательностей операций, которые регулярно используются в АРМе Каталогизатор.

В качестве примера предлагается пакетное задание TEST.IBF, с помощью которого реализуется корректировка мест хранения для экземпляров, поступивших по определенному КСУ.
Пакетное задание TEST.IBF имеет вид:

test_ibf.wss
SEARCH "NKSU=%1"
GLOBAL test_ibf
OPERANDSEP ;
PRINT 0;test_ibf;;;Экземпляры, поступившие по КСУ %1, для которых место хранение %2 заменено на %3 <table border=1>;;1/c:\irbiswrk\test.htm

РЛ test_ibf.wss используется для задания трех переменных параметров:
-НОМЕР КСУ
-СТАРОЕ МЕСТО ХРАНЕНИЯ
-НОВОЕ МЕСТО ХРАНЕНИЯ

Переменные параметры (т.е. конструкции %1 %2 %3) используются в тексте пакетного задания, а также в тексте задания на глобальную корректировку test_ibf.gbl:

0
REP
910^D
F
&uf('+7W10#'),(if p(v910) then if p(v910^D) then if &uf('+97',v910^U)='%1' then if &uf('+97',v910^D)='%2' then '%3',,,&uf('+7W10#Место хранения изменено. MFN=',f(val(mfn),0,0),' Инв.номер - ',v910^B ) else v910^D fi else v910^D fi else # fi fi/)

PUTLOG
g10

и в тексте формата печати test_ibf.pft

'<tr>',
'<td valign=top>',
&uf('6brief'),
'</td>',
'<td valign=top>',
(if p(v910) then if v910^U='%1' then v910^B|<br>| fi fi),
'</td>',
'</tr>'

По данному пакетному заданию:
- выполняется отбор документов по заданному КСУ
- в отобранных записях выполняется глобальная корректировка мест хранения для экземпляров по заданному КСУ
- выполняется печать откорректированных записей с указанием инв.номеров экземпляров, для которых было изменено место хранения.

Пользователи ИРБИС64 2012.1 и 2013.1 могут получить для тестирования данного решения предварительную версию АРМа Каталогизатор 2014.1. Обращаться на alio@gpntb.ru



Редактировано 3 раз. Последний раз 13.01.2014 07:21 пользователем Alio.

Возможно ли в следующей версии реализовать автосохранение записи (в фоновом режиме). Актуально при вводе оглавления или реферата на многих языках.

Т.е чтобы программа вместо Вас с какой-то периодичностью "нажимала" кнопку СОХРАНИТЬ?

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

Кстати, не пора ли начинать вводить в версии 2014 новые пользовательские инструменты? Предлагаю библиографический редактор, который можно было бы вызывать из Каталогизатора и автоматизировать с его помощью формирование записи и ввод оглавления из исходного текста. Кроме скоростного ввода оглавления, специализированный язык библиографической разметки (BIRMA) может по идее быть полезен при ретроконверсии. Наработки имеются, надо только довести их "до ума". Готов поделиться своими наработками и помочь с реализацией.

Нет, уточню. Каждый ввод данных осуществляется нажатием на одноименную кнопку "ВВОД". Для сохранения введенных данных в базу необходимо нажать на кнопку "Сохранить". Автосохранение объединяет сразу две функции "ВВОД" и "Сохранить". Для ускорения процесса можно запись не актуализировать. А актуализировать при "нормальном" сохранении записи.

А что за кнопка "ВВОД"? Нигде не видел такой. Любую запись можно начинать вводить сразу после того, как в таблице выбрана соответствующая ей строка в БД. Или это предлагаемое нововведение?

А как вы по-другому укажите программе какие данные писать в базу? Кнопка "ВВОД" присутствует, например, для поля 331. Находится на форме слева внизу. После нажатия на эту кнопку, кнопка сохранить на панеле инструментов становится активной. Вы не полностью разобрались в том, что я предлагаю, или я, возможно, не так описал. Запустите АРМ-Каталогизатор, зайдите на страницу "Систематизация", найдите поле 331: Аннотаци, ну и F2. вы сами увидите, что она есть. Я предлагаю сделать автосохранение записи через определенное время работы с записью и ее полем (подполем). Под автосохранением понимаю автоматическое нажатие сначала на кнопку "ВВОД" (подтверждение ввода данных) и последующее сохранение данных в БД.
Коротко говоря, автоматически подтверждать ввод данных и их сохранение в БД.



Редактировано 1 раз. Последний раз 27.11.2013 20:22 пользователем woodyfon.

А, теперь понял: имеется в виду кнопка "ВВОД" модальной формы, содержащей таблицу подполей для конкретного поля, или список для выбора значений поля, или текстовый редактор. Просто Вы писали, что каждый ввод данных осуществляется нажатием на одноименную кнопку "ВВОД", а в то же время есть такие поля, редактирование которых происходит в соответствующих ячейках таблицы, без необходимости вызова вложенных форм.

Да, безусловно, функция автосохранения должна учитывать то, что пользователь в данный момент может работать с модальной формой редактирования конкретного поля. Но и если это не так, на мой взгляд, эта функция всё равно должна быть доступной. Нужно просто установить определённый промежуток времени в зависимости от скорости работы оператора, по истечении которого запись сохраняется в базе данных. Чтобы это не мешало работать, данный процесс должен происходить в отдельном потоке.



Редактировано 1 раз. Последний раз 28.11.2013 08:21 пользователем S-presso.

В дополнение к этому пожеланию:

Цитата:

Денисова Лариса
Александр Иосифович, напоминаю свою просьбу, озвученную на Либкоме.Параметрировать возможность выбора интерфейса для РЛ подполей.

Хотелось бы ещё иметь возможность работать со всеми повторениями текущего поля, не выходя из модальной формы со вложенной таблицей подполей и переходя от одного повторения к другому с помощью кнопочек со стрелками. Конкретная реализация тут может быть на усмотрение разработчиков: либо элемент типа SpinEdit, находящийся рядом с таблицей подполей и содержащий номер конкретного повторения, либо такой же элемент, внедрённый в саму таблицу. И, конечно, должна быть предусмотрена возможность отключения этой возможности и работы с прежним интерфейсом (чтобы по умолчанию всё было, как раньше).

Ещё раз приведу соответствующий скриншот из моей старой программы:

А чем Вас не устраивает табличный ввод (F3)?

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

S-presso написал(а):
-------------------------------------------------------
> Поскольку поле содержит слишком много подполей,
> чтобы их все можно было уместить в колонках на
> одном экране в режиме табличного ввода, для работы
> с отдельным повторением в этом режиме таблицу
> пришлось бы всё время прокручивать. А хотелось бы
> видеть на экране содержимое всех подполей, и в то
> же время иметь возможность быстрого перехода к
> другому повторению. И чтобы при нажатии кнопки
> "ВВОД" сохранялись все произведённые изменения над
> каждым из повторений поля.
Предложение интересное - подумаем...

Хотелось бы узнать мнение пользователей по поводу описания ЭЛЕКТРОННЫХ РЕСУРСОВ.
Каких элементов данных не хватает для описания таких ресурсов?
Применима ли для таких документов (описаний) технология книговыдачи - и если да, то каким образом?

Здесь под электронным ресурсом понимается ресурс, который НЕ СВЯЗАН С КАКИМ-ЛИБО ФИЗИЧЕСКИМ НОСИТЕЛЕМ, т.е. такой ресурс имеет или URL или сетевой путь (и ничего больше).

Alio написал(а):
-------------------------------------------------------
> S-presso написал(а):
> --------------------------------------------------
> -----
> > Поскольку поле содержит слишком много подполей,
> > чтобы их все можно было уместить в колонках на
> > одном экране в режиме табличного ввода, для
> работы
> > с отдельным повторением в этом режиме таблицу
> > пришлось бы всё время прокручивать. А хотелось
> бы
> > видеть на экране содержимое всех подполей, и в
> то
> > же время иметь возможность быстрого перехода к
> > другому повторению. И чтобы при нажатии кнопки
> > "ВВОД" сохранялись все произведённые изменения
> над
> > каждым из повторений поля.
> Предложение интересное - подумаем...
Сделано.
АРМ Каталогизатор ИРБИС64

В интерфейс ввода повторяющихся полей с помощью РЛ подполей введены дополнительные кнопки-ускорители (см. прикрепленный рисунок), которые позволяют одним нажатием переходить к следующему или предыдущему повторению поля с сохранением или отказом от ввода.

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

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

Суть в том, что в сборниках статей и других изданиях эта информация не всегда представлена так, как её надлежит переносить в ЭК - например, инициалы авторов статей стоят в начале, до фамилии, а не в конце, сама фамилия может быть набрана заглавными буквами; также возможно совмещение первого и второго. Заглавия статей также могут быть набраны заглавными буквами. Чтобы не перепечатывать эти данные вручную, но и не оставлять их в базе в таком виде, я предлагаю ввести страничку инициализации подполей - у меня в программе она появлялась при переходе к "нулевому" повторению, т.е. если при просмотре первого повторения поля нажать кнопку со стрелкой назад.

Далее, вводим несколько дополнительных MNU-файлов (или каких-нибудь других) для тех подполей повторяющихся полей, для которых возможна корректировка. Например, там может быть такое содержимое (пусть это будут файлы 330^f_cor.mnu, 330^1_cor.mnu, 330^2_cor.mnu):

1
Перевести содержимое поля в нижний регистр
2
Поменять местами фамилию и имя
3
Разделить фамилию и имя на отдельные подполя

Тогда при выборе из таблицы на странице настроек (на "нулевом" повторении) поля 330 строки с соответствующим подполем будет показан список из таких 3-х пунктов. Но, поскольку, как легко заметить, все три параметра могут совмещаться в различных комбинациях (при этом вместо "Поменять местами фамилию и имя" может следовать "Поменять местами фамилию и инициалы", но для программы это не важно), вместо простого ListBox 'а или Combobox'а здесь лучше использовать список из Checkbox'ов, возможно, совмещённый с Combobox'ом (хотя в стандартной палитре такого компонента нет). Далее, с каждым из таких файлов может быть связан другой файл, описывающий действия, производимые при выборе одного из элементов списка настроек подполя, или при установке его флажков. Его содержимое в данном случае может быть следующим (здесь используется не какой-либо встроенный язык Ирбис64, а мой собственный синтаксис, но думаю, что смысл понятен: call_func - вызов функции, val - текущее значение подполя, выполняется для всех повторений):

1=&call_func('toLower', val)
2=&call_func('userfunc', 'postprocess.dll', 'transferInitials', val)
4=&call_func('userfunc', 'postprocess.dll', 'splitName', val)
3=&call_func('userfunc', 'postprocess.dll', 'transferInitials', &call_func('toLower', val))
5=&call_func('userfunc', 'postprocess.dll', 'splitName', &call_func('toLower', val))
6=&call_func('userfunc', 'postprocess.dll', 'splitName2', val)
7=&call_func('userfunc', 'postprocess.dll', 'splitName2', &call_func('toLower', val))
CommonCode=toLower(arg):=result:=&call_func('userfunc', 'postprocess.dll', 'toLowerName', arg)

Здесь перед знаком равенства в строках идёт номер, соответствующий бинарной величине данной комбинации параметров (являющейся суммой весов каждого выбранного параметра из списка, при условии, что первый параметр ("Перевести содержимое поля в нижний регистр") имеет вес 1, а последующие - весы 2, 4,... 2**n). После знака равенства следует действие: вызов соответствующей пользовательской функции из библиотеки postprocess.dll или комбинация двух вызовов функций. Последней строкой идёт определение самой функции toLower(). Если следовать синтаксису Си, эту строку можно было бы записать как-то так:

#define toLower(arg) &call_func('userfunc', 'postprocess.dll', 'toLowerName', arg)

Если бы это было описание действий над подполем "Заглавие", строка могла бы быть такой:

#define toLower(arg) &call_func('userfunc', 'postprocess.dll', 'toLower', arg)

Здесь toLower(), toLowerName(), transferInitials(), splitName(), splitName2() - это функции из моей библиотеки postprocess.dll, принимающие один строковый параметр и производящие нужные действия над этой строкой. toLower() отличается от toLowerName() тем, что в первом случае вся строка переводится в строчный регистр, за исключением первой буквы, которая должна остаться заглавной в подполе "Заглавие", а в toLowerName() строка ещё разбивается на отдельные подстроки, каждая из которых (одно из имён автора или инициал) всегда должна начинаться с заглавной буквы.

Исходники библиотеки postprocess.dll на Borland C++ прикладываю к этому сообщению. Конечно, у каждого администратора системы может быть своя собственная DLL-ка с реализацией нужных ему функций. Или Вы можете выбрать какое-то своё решение этой проблемы, если, конечно, она представляется Вам заслуживающей внимания, отличающееся от моего.

АРМ Каталогизатор ИРБИС64

Обеспечена возможность оперативной корректировки ОПРЕДЕЛЕННЫХ СПРАВОЧНИКОВ.
В связи с этим в раздел СЕРВИС главного меню введен новый режим КОРРЕКТИРОВКА СПРАВОЧНИКОВ.
Список справочников доступных для корректировки определяется параметром в секции [MAIN]
MnuMnu=
(по умолчанию - mnu.mnu)
Список доступных справочников, так же как и собственно корректируемые справочники, должны находиться в папке БД или в DEPOSIT.
Также введен параметр в секции [MAIN]
Mnuable=
который определяет ДОСТУПНОСТЬ (значение 1 - по умолчанию) данного режима.
Собственно интерфейс (редактор) для корректировки справочников представлен на прилагаемом рисунке.
Редактор позволяет:
- отмечать строки для их удаления (в т.ч. с помощью клавиши Shift для групповой отметки)
- вставлять новые строки
- перетаскивать строки

Моя предыдущая идея, видимо, слишком сложна для реализации в штатных приложениях Ирбис . Но есть ещё одно предложение, касающееся нового функционала для разработчиков - то, что я, кстати, пока не смог сам реализовать в своём АРМе.

Я предлагаю добавить в Каталогизатор поддержку пользовательских плагинов, написанных с помощью управляемого кода, т.е. с помощью любого языка .NET. Ведь не секрет, что в настоящее время многие программисты предпочитают традиционным средам программирования, таким как Delphi, новые языки и среды разработки - VB.NET, C# и др. Я сам собираюсь переводить свой плагин библиоредактора на C#. Возникает проблема подключения таких подпрограмм, написанных на управляемых языках, к Ирбису (или любой другой системе с поддержкой плагинов традиционного типа).

Существует коммерческая система разработки плагинов, поддерживающая подобное межплатформное взаимодействие - [www.remobjects.com], однако цена вопроса - 400 долларов. Свободных аналогов я не нашёл. Правда, управляемые плагины теоретически можно подключать к модулям, написанным на Delphi, C++ и др., с помощью бесплатной утилиты ExportDll, выложенной на [www.codeproject.com], о чём я уже писал здесь - [irbis.gpntb.ru]. Но как-то коряво выходит - все вызываемые извне подпрограммы приходится вручную помечать как управляемые, да и сама утилита требует настройки. Намного лучше было бы, если бы к самому АРМ Каталогизатор был привязан некоторый универсальный управляемый плагин-прослойка (DLL-ка на .NET), который уже в свою очередь позволял бы вызывать нужные методы из других DLL- или EXE-файлов.

Для поддержки .NET-плагинов можно было бы добавить в файл инициализации Cirbisc.ini параметр вроде UMDLLNETn - то же, что и UMDLLn, но определяющий имя файла для управляемого приложения-плагина. В остальном способ подключения пользовательских модулей можно оставить без изменений. При выполнении каждого такого плагина можно было бы вызывать универсальную прослойку (назовём её, допустим, DLL2NET.DLL), в вызываемый метод которой (помеченный как неуправляемый средствами ExportDll) передавать, кроме переменных, отвечающих за входную и выходную записи, и размера буфера (buf1, buf2 : PChar; bufsize : Integer в интерфейсе на Delphi), ещё и два строковых значения - имя файла вызываемого плагина и имя его выполняемого метода (функции).

Конечно, это только один из возможных способов решения задачи. Возможно, есть и лучше. Но, в любом случае, как мне кажется, эта задача представляет определённый интерес.

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

Жаль, что это так. Хотя плагинов может быть мало ещё и как раз по причине отсутствия надёжного механизма пристыковки .NET-кода. Может, имеет смысл хотя бы просто добавить ещё один прототип функции для плагинов, позволяющий кроме входной и выходной записей и размера буфера указывать ещё имя файла плагина и вызываемой функции? А реализацию нужных прослоек оставить на откуп пользователям.

Александр Иосифович, у меня ещё одна идея, которую, кажется, несложно было бы реализовать. Насколько мне известно, все текстовые данные, которые передаются в приложения ИРБИС64 через буфер обмена Windows, обрезаются до первого вхождения символа перевода строки. Из-за этого часто приходится копировать - вставлять один и тот же текстовый фрагмент по несколько раз. Может быть, имеет смысл просто заменять во вставляемых из буфера фрагментах все последовательности "\r\n" (или '$13$10') на символы пробела? Можно было бы также опционально заменять несколько пробелов и/или символов табуляции на один пробел.

S-presso написал(а):
-------------------------------------------------------
> Жаль, что это так. Хотя плагинов может быть мало
> ещё и как раз по причине отсутствия надёжного
> механизма пристыковки .NET-кода. Может, имеет
> смысл хотя бы просто добавить ещё один прототип
> функции для плагинов, позволяющий кроме входной и
> выходной записей и размера буфера указывать ещё
> имя файла плагина и вызываемой функции? А
> реализацию нужных прослоек оставить на откуп
> пользователям.
>
> Александр Иосифович, у меня ещё одна идея,
> которую, кажется, несложно было бы реализовать.
> Насколько мне известно, все текстовые данные,
> которые передаются в приложения ИРБИС64 через
> буфер обмена Windows, обрезаются до первого
> вхождения символа перевода строки. Из-за этого
> часто приходится копировать - вставлять один и тот
> же текстовый фрагмент по несколько раз. Может
> быть, имеет смысл просто заменять во вставляемых
> из буфера фрагментах все последовательности "\r\n"
> (или '$13$10') на символы пробела? Можно было бы
> также опционально заменять несколько пробелов
> и/или символов табуляции на один пробел.
В АРМе Каталогизатор НЕТ НИКАКОГО контроля данных, передаваемых через буфер обмена Windows.

Цитата:

Alio
В АРМе Каталогизатор НЕТ НИКАКОГО контроля данных, передаваемых через буфер обмена Windows.

Ну, значит, именно поэтому при копировании многострочного текста вставляется только первая строка. Может, стоит ввести такой контроль, с заменой разделителей строк на пробелы? Полезно при вводе таких распознанных после сканирования элементов библиографической записи, как, например, аннотация, подполя оглавления.

Копирование/Вставка данных из буфера Windows осуществляется на уровне применяемых компонентов - которые настроены на работу с ОДНОСТРОКОВЫМИ данными.

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

Прошу прощения, а в чем проблема? Метод ввод 8 и его параметры:

IRBISOUT0 - предполагает, что ввод вызван или нажатием на кнопку ввода в поле, или по клавише F2. После обработки и возврата данных в Ирбис, они будут помещены в ОДНО ПОВТОРЕНИЕ поля. Если при вызове программы для ввода поле уже не пустое, то следом за приведенной командой передается содержимое поля.

IRBISOUT1 - предполагает, что ввод вызван клавишей F3, а результат надо вернуть в виде набора строк, каждая из которой станет ОТДЕЛЬНЫМ ПОВТОРЕНИЕМ поля. Аналогично передаются в программу данные, если поле не пустое. При наличии нескольких полей и вызове одного из них, будут переданы во внешнюю программу данные только из этого повторения.

S-presso написал(а):
-------------------------------------------------------

> Александр Иосифович, у меня ещё одна идея,
> которую, кажется, несложно было бы реализовать.
> Насколько мне известно, все текстовые данные,
> которые передаются в приложения ИРБИС64 через
> буфер обмена Windows, обрезаются до первого
> вхождения символа перевода строки. Из-за этого
> часто приходится копировать - вставлять один и тот
> же текстовый фрагмент по несколько раз. Может
> быть, имеет смысл просто заменять во вставляемых
> из буфера фрагментах все последовательности "\r\n"
> (или '$13$10') на символы пробела? Можно было бы
> также опционально заменять несколько пробелов
> и/или символов табуляции на один пробел.

А по этому поводу вот что написанно в Релизе к версии 2012.1:

Расширены возможности МЕТОДА ВВОДА 4 (через многостроковое окно) (ИРБИС64):
- при мультивводе повторяющихся полей (F3) каждый абзац введенного текста (абзац - часть текста, отделенная с помощью клавиши Enter) принимается как отдельное повторение поля;
- при мультивводе в одно поле/подполе (если указаны данные в 10 свойстве данного поля/подполя в описании РЛ - см. Общее описание системы Приложение 8 п.5.1) осуществляется объединение абзацев введенного текста по соответствующим правилам.
В качестве примера см. мультиввод (F3) в поле 331 (Аннотация).

См. ВАЖНОЕ ДОПОЛНЕНИЕ в сообщении от 26 ноября 2013 в этой ветке.

АРМ Каталогизатор ИРБИС64

Расширен набор команд для ПРОИЗВОЛЬНЫХ ОПЕРАТИВНЫХ РЕЖИМОВ (см. релиз 2013.1 АРМ Каталогизатор п.5)

- Код команды: 4 - ВЫПОЛНИТЬ ПАКЕТНОЕ ЗАДАНИЕ, структура параметров: <ИМЯ_ПАКЕТНОГО_ЗАДАНИЯ>;

- код команды: 5 - ВЫПОЛНИТЬ РЕЖИМ ПОЛЬЗОВАТЕЛЯ (см. релиз 2006.1 АРМ Каталогизатор, п.4), структура параметров: <имя_DLL>,<имя_функции>,<@имя_формата|формат>;

- код команды: 10 - то же самое, что команда 0 - но в качестве параметра вместо <формат_запроса> задается собственно <запрос>;

- код команды: 11 - то же самое, что команда 1 - но в качестве параметра вместо <формат_запроса> задается собственно <запрос>;

- код команды 100 - эммуляция "жесткого" оперативного режима РЕГИСТРАЦИЯ, не имеет параметров;
- код команды 101 - эммуляция "жесткого" оперативного режима НОМЕРА, не имеет параметров;
- код команды 102 - эммуляция "жесткого" оперативного режима ФОРМИРОВАНИЕ ПОДШИВКИ, не имеет параметров;
- код команды 103 - эммуляция "жесткого" оперативного режима СВОДНЫЙ, не имеет параметров;
- код команды 104 - эммуляция "жесткого" оперативного режима СТАТЬИ, не имеет параметров;
- код команды 105 - эммуляция "жесткого" оперативного режима ДРУГИЕ НОМЕРА, не имеет параметров;
- код команды 106 - эммуляция "жесткого" оперативного режима НОВАЯ СТАТЬЯ, не имеет параметров;
- код команды 107 - эммуляция "жесткого" оперативного режима НОМЕРА ПОДШИВКИ, не имеет параметров;
- код команды 108 - эммуляция "жесткого" оперативного режима ИСТОЧНИК, не имеет параметров;
- код команды 109 - эммуляция "жесткого" оперативного режима ДРУГИЕ СТАТЬИ, не имеет параметров.

Команды 100-109 реализованы для того, чтобы имелась возможность СОВМЕЩАТЬ ЖЕСТКИЕ и ПРОИЗВОЛЬНЫЕ ОПЕРАТИВНЫЕ РЕЖИМЫ

ИРБИС64 АРМ Каталогизатор
Введен новый параметр в секции [MAIN]
MAXBINRESOURCE=
определяющий максимальный размер внутреннего двоичного ресурса (в кбайтах). По умолчанию - 50