Версия 2013 D5
1. При отметке в окне переноса одной записи (БД ЭК, словарь "Дисциплина") и вызове на Ввод/Корректировку отбираются не одна отмечена запись, а все документы, на которые есть в словаре
Баг???
2. Кнопка "Удаление данных в записи" должна быть не активна по умолчанию. Были случаи, когда возникало окно удаления с пустой строкой. При отметке - ERROR
3. Очень не хватает подробного отчета о изменениях. Не всегда тексты сообщений при ГК совпадает с действительностью.
4. Нет возможности множественного выбора БД ЭК, чтобы получить общий список литературы.

P.S. Тему создавал, чтобы обратить внимание разработчиков.
Pre Alpha...

1 Нет иначе нельзя Так работает словарь Просто вы снимаете все отметки и делаете какие вам нужны См 1
2 ERROR - это наверное баг. Но активность этой кнопки определяется в irbisk.ini
3 А вы релизы читаете? Там недостаточно подробно?
4 Некоторые средства есть. Надо перейти на 2015 и тогда сделать свои замечания. Мы не модернизируем старые версии

Цитата:

1 Нет иначе нельзя Так работает словарь Просто вы снимаете все отметки и делаете какие вам нужны См 1

Мы так и делаем. Снимаем все отметки и ставим отметку только на одной записи, нажимаем на кнопку "Применить", получаем сообщение о количество отмеченных записях. Такое количество можно наблюдать в строке состояния.

Цитата:

Но активность этой кнопки определяется в irbisk.ini

Видимость, а не активность, этой кнопки должна определяться в файлике конфигурации. Активность в зависимости от действий пользователя.

Цитата:

А вы релизы читаете? Там недостаточно подробно?

К сожалению, прочтение релизов с некоторых пор, неактуально - утратили действия договора сопровождения. Если, Вам не трудно, укажите, пожалуйста, какие именно изменения Вы имели в виду. Неписанные правила говорят, что если были замеченны существенные баги, то разработчик должен выпустить исправления (fix) (нередко они называются горячими исправления hotfix)

Цитата:

Некоторые средства есть. Надо перейти на 2015 и тогда сделать свои замечания. Мы не модернизируем старые версии

У нас нет возможности приобретения новой версии модуля КО, также кажется неоправданной. Но если нельзя, то будет обходиться тем, что есть.

В версии 2013 уже добавлена возможность подцеплять другие БД ЭК. Посмотрите релиз для КО, п. 1.12.

Добавление дополнительных БД было реализовано в отдельных формах отчета. Под множественным выбором БД понимаю возможность просмотра связанных данных (просмотр полного списка литературы). Сейчас, если используется несколько БД ЭК, необходимо выбирать каждую БД и просматривать в отдельности список литературы.
Может, стоит добавить множественный выбор БД и списке и расширить просмотр сведений о документах, указав БД назначения?

Т.е. недостаточно, что БД подцепляются при формировании ККО - см. 111?
Надо, чтобы списки составлялись для нескольких БД?

Без количества студентов нет смысла считать ККО. Сейчас, чтобы определить какие книги подцепились к дисциплине а какие - нет, необходимо последовательно провести поиск в каждую из используемых БД ЭК. Поиск проводится либо через просмотр записей в каждой БД, либо через словарь. Т. е. лишних движений тем больше, чем больше БД ЭК.

Буду пробовать, хотя это рушит существующую логику

Сейчас основное окно и окно переноса не связаны между собой на уровне действия оператора. Приходится дважды выполнять поиск (вводить поисковый запрос в поле "Ключ") даже в том случае, если выбраны одна и та же БД и Вид поиска.
Поэтому маленькое предложение:
добавить возможность переноса поискового запроса в другое окно, естественно, если выбраны однотипные словари.

Нет, не согласна. Правое окно тем и хорошо, что оно независимо и с ним можно работать в паралель с основным. Например сравнивать разные словари разных БД.
Как такового ведь запроса нет, а то что в ключе - это не запрос а позиция словаря. Почему правое окно должно вставать в ту же позицию, что и основное?
А вы в курсе такого интересного режима - поиска заглавия из БД каталога опн.словаря в БД каталога (другой) правого словаря? см. 111

Цитата:

Почему правое окно должно вставать в ту же позицию, что и основное?

Может вставать, а не должно. Обычно ключи совпадают.

Цитата:

А вы в курсе такого интересного режима - поиска заглавия из БД каталога опн.словаря в БД каталога (другой) правого словаря? см. 111

Укажите, пожалуйста, версия, для которой реализована эта опция. Что-то подобное я имел в виду, но для всех словарей.



Редактировано 1 раз. Последний раз 21.03.2016 09:15 пользователем woodyfon.

Испытала для версии 2013 - работает, см. 1.

В нашей версии такого режима нет. Кнопки в основном окне не наблюдаю. Каким образом ее можно сделать?

Напишите мне на почту, я вам вышлю то, что у меня в версии 2013

Получил сообщение об ошибке "Cannot make a visible windows mode" при удалении контингента из дисциплины.
Может, удастся смоделировать ошибку:
1. В правом окне выбрать БД VUZ
2. Выбрать вид словаря "Дисциплина".
3. Отметить дисциплину и нажать на кнопку "Удалить данные в записи".
4. Можно отметить данные на удаление.
При повторном нажатии на кнопку "Удалить данные в записи" получаю сообщение об ошибке.
+
Приходится завершать работу модуля.
Может, лучше окно удаления сделать по настоящему модальным, а кнопку - неактивной?



Редактировано 1 раз. Последний раз 28.03.2016 14:59 пользователем woodyfon.

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

Это попытался выполнить перед как написать отчет. Найти такое окно не удалось.

Версия 2013.1. Обновление D5
При добавлении нового контингента не осуществляется проверка в БД наличия такого контингента в БД VUZ. Как следствие, создается новая запись типа VUZ, а не выполняется добавление повторения поля 69.
Задание vAdd83.gbl (дата сохранения файла 20.02.2014) прикреплено.
Мне кажется, что ошибка закралсь в строке под номером 92. Не пытаюсь сам исправить файлик - боюсь нарушить логику работы.
+
Также в проверке необходимости добавления нового повторения поля 69 не участвует подполе ^C (Специальность), а только ^N. Это исключает вариант, когда заполняется специальность.
P.S.
У нас "Направление" и "Специальность" взаимоисключающиеся сведения. Специальность - это Направление + 1-3 дополнительных семестра со своими дисциплинами.
+
В файлике vAdd83.gbl идет проверка на добавление повторений поля 83 из модельного поля 991. В проверке не берется во внимание, что подполе ^F может содержать несколько семестров, следующих через косую черту. В этом случае условие val(v83^F)=val(&uf('Av991^F#1')) не будет принимать значение true. Значение функции f(val(v83^f),0,0) будет равняться первому семестру идущей до косой черты (слеша "/"). Следовательно, если семестр добавляемого контингента стоит не первым, то будет добавление повторения поля. Такого не должно быть. Поэтому необходимо добавить условие сравнения с полем 83, предварительно проведя его корректировку (размножив семестры) с целью избавиться от слеша.



Редактировано 3 раз. Последний раз 04.04.2016 12:37 пользователем woodyfon.

Версия 2013 D5
При переносе контингента (VUZ) в запись дисциплины (DISC) в БД VUZ автоматический не формируются сведения в поле 69: Кафедра-дисциплина в записи контингента (VUZ). Следовательно при просмотре контингентов в области связанных данных такого контингента нет. При этом добавление нового повторения поля 83 происходит. Такой вариант добавления контингента предлагается в инструкции.
Аналогичный тому варианту, который предлагается делать через кнопку добавления контингента в правом окне. В этом случае новое повторение в поле 69 добавляется.
Проблемы, охарактеризованы в сообщениях выше, взаимосвязаны, поскольку в задании Move83.gbl вызывается на выполнение задание vAdd83.gbl. Возможно, исправление задания vAdd83.gbl решат их.
+
В поле 84 добавляются повторения из поля 991. Ни в ГК vAdd83.gbl, ни в текущей это поле не используется. Видимо ошибка кроется в другом задании.
+
Ошибка тянется линией через операторы ГК, в формате которых есть перебор повторения поля 83^f. Ведь там может разделитель семестров. СЛедовательно, предварительно необходимо от него избавиться.



Редактировано 5 раз. Последний раз 04.04.2016 14:48 пользователем woodyfon.

Первое замечание. Мне проще приложить то задание, которое последнее. Но и в нем, и в вашем делается проверка на наличие такой же записи VUZ - есть такой комментарий. Другое дело, что вы указали на ошибки, спасибо.
1. Строка 92 - это недоразумение, она вообще не к чему не относится, осталась видимо от отладок. Но она не влияла, т.к. была вне оператора.
2. В след. операторе проверяется наличие записи VUZ, и этот формат я исправила. Результат прикладываю отдельно. В этом формате был повтор кода, убрала. Еще в нем учитывается ситуация, когда есть два похожих контингента, но в одном задано направление, а в другом это же значение, но в специальности. Сделана разводка таких контингентов. НО! это не было учтено в файле autoink.gbl. Исправила
3. vAdd83.gbl. То что вы обнаружили - неважно. Главное, что новый контингент добавляется (потому что FALSE). И главное, что в третьем проходе (vDel83) старое удаляется из повторения (со слэшом). Но... У вас это должно работать, а в версии 2015 я добавила в vDel83 опрос и оно перестало удаляться. Срочно исправляю и в D3.
Прикладываю исправленные задания и для интереса развернутый формат проверки.

Я проверила ситуацию в 2015 - там новое поле 69 формируется. Прежде чем разбираться в 2013, попробуйте взять ГК из 2015 (vAdd83 вы уже взяли).

Спасибо, будем пробовать, разбираться.

Цитата:

Прежде чем разбираться в 2013, попробуйте взять ГК из 2015 (vAdd83 вы уже взяли).

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

Цитата:

Сделана разводка таких контингентов. НО! это не было учтено в файле autoink.gbl.

Выполнение такого задания будет всегда? Совсем забыл, что может быть еще и пост ГК, которая и может изменить результаты непосредственно заданий на добавление контингентов / перенос.

Подскажите, пожалуйста, в каком именно задании ГК должно быть окончательное добавление повторения поля 69?

+
При вызове задания vAdd83 не удается определить номер записи, куда следует добавить повторения поля 69, ведь модальное поле 991 пустое. Т. е. Нет данных о добавляемом контингенте. Может, в поле 1932 следует занести содержимое поля 84. И делать сравнение каждого повторения поля с полем 83?



Редактировано 4 раз. Последний раз 05.04.2016 09:21 пользователем woodyfon.

"Выполнение такого задания будет всегда?" - вы имеете в виду autoink.gbl? Этот файл прописан как параметр автоввода в irbisk.ini, так что это задание выполняется всегда.
Многие задания формируют поле 69. Последний аккорд - выполнение режима "Связать..."
А зачем вызывать задание vAdd83? Оно вызывается из программы, при этом программа сама вставляет в него поле 991. Объясните необходимость. Есть такие задания как LinkDisc, LinkVuz, их можно вызывать как самостоятельные. Но все делается, чтобы у вас не возникало таких намерений.

Цитата:

А зачем вызывать задание vAdd83? Оно вызывается из программы, при этом программа сама вставляет в него поле 991.

Вручную задание vAdd83 не вызываю, его вызывает задание Move83 строкой

'LINKCORRTASK=VADD83%MFN=',,,,f(val(mfn),0,0)

Необходимо отладить код задания vAdd83. По идее значение модального поля 991 не должно быть пустым и равняться записи контингента (поле 68). Но оно по прежнему пустое, поэтому в задании vAdd83 и не заносятся сведения в поле 69. Хотя задание vAdd83 прекрасно отрабатывает при добавлении контингентов через одноименную кнопку в окне переноса. Может, необходимо использовать проверку не поля 991, а переменной, как признак запуска задания и данных для добавления поля 83?
+
Значение модального поля 991 в задании vAdd83 в нашей версии программы всегда пустое.



Редактировано 1 раз. Последний раз 05.04.2016 10:58 пользователем woodyfon.

Дошел до отладки задания LINKDISC.
Но при выбранных условиях

if v992<>'' and v920='VUZ' then '1' else '0' fi

и при переносе контингента в запись дисциплины, такое задание не будет запускаться, так как РЛ = DISC. Следовательно, не будут изменяться уникальные номера дисциплин (v83^W).
Проблема добавления повторений поля 69 удалось решить путем добавления переменной. Но теперь встала задача изменить/добавить Уникальные номера дисциплин.
Какое задание это выполняет?



Редактировано 1 раз. Последний раз 05.04.2016 14:42 пользователем woodyfon.

Баг 1:
При переносе контингента в записи ЭК не сравнения на наличие первого в поле 691.
Баг 2:
При изменении идентификатора дисциплины (заменить старое значение на новое REPMark) не менется подполе W (уникальный номер дисциплины).

1. Убедили - перенос контингента в записи дисциплин надо пересмотреть. Прямо сейчас не могу, но в ближайшие 2-3 дня сделаю
2. С 69^W - другая история. Я это понятие - уникальный номер дисциплины - убрала. Это было введено в начале разработки не мной. Исходили из незыбленности один раз автоматически присвоенных значений. Но оказалось, что все постоянно меняется и невозможно отслеживать значения УНД. Вернее можно, но очень затратно. А без этого параметра вполне можно обойтись, т.к. достаточно других параметров - ИД + контингент. Зачем вводить новые сущности?
Так что вы просто не обращайте на него внимание. Он почти (в 2015 точно) нигде не используется. (Если надо - могу выяснить где для вашей 2013)

Разъясните, пожалуйста, ситуацию касательно запуска других заданий. Вы утверждаете, что поле 991 программа сама заполняет, но в нашей версии такого не наблюдаю. Приходится данные помещать предварительно в глобальные переменные. И уж затем работать с ними в вызванном задании.
Какой признать того, что данные "связанные" между собой.

Цитата:

Если надо - могу выяснить где для вашей 2013

Пожалуйста, пытаемся, чтобы тип данных был унифицированным. Также в собственных исправлениях заданий участвует УНД. Интересно, формирование подполя ^W и ^9.

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

Что значит "запуск других заданий"? Вы имеете в виду из строки PUTLOG (PUTFLD)? Это скрытая технология, которая менялась. В последнем варианте - это параметры, одним из них м.б. поле 991. Например в задании RepItem:

'LINKCORRTASK=RCHA90%DBN=RDR%QUERY="SPEC=',,v991^A,,,'"%V991=',"^A"v991^A,"^B"v991^1,'^CC',,'%'

" поле 991 программа сама заполняет " - это относится только к заданиям на перенос данных. Поля 991, 992, и др. определяет файл типа fst. Имена файлов задаются в irbisk.ini. Например: 1