Как лучше сделать в форме историю ответных документов?

[masyna]

Доброго всем вечера Господа!!!

Такая проблемка, хочу чтобы в одной из главных форм отображались в виде истории ответы на эту форму, которые можно отрыть тут же из формы!! Я думаю что это делается с помощью встроенной вью, но как это сделать не знаю!! Помогите решить задачку, желательно со всем листингом, если он вообще будет))))

И вот еще что хотелось бы у вас попросить, может кто скинуть пример базы с динамическим выбором документов, с помощью формы выбора??? Очень буду благодарен!!!

Да Я забыл сказать. Я в этом деле новичок, поэтому может вопрос покажется и глупым)))))

 

[Akupaka]

Я в этом деле новичок

судя по всему, в изучении справочной системы ты тоже новичек? ))

внедренный вид имеет свойство "Show single category" - это можно почитать в справке.
работает это свойство в паре с видом таким образом, что вид фильтруется по первой категоризированной колонке.

например, если по твоей задаче построить вид, который отбирает только дочерние документы к документам по заданной форме, то первая категоризированная колонка может быть сформированна по формуле:

@Text($REF)

а свойство внедренного вида "Show single category" на форме родительского документа может иметь значение:

@Text(@DocumentUniqueID)

 

[TIA]

Встроенная вью добавляется на форму через меню "Create\Embedded Element\View". В св-вах встроенной вьюшки на второй закладке есть галка "Show only current thread". Она означает, что должна отобразиться то дерево респонсных документов из указанного вью, в которой содержится текущий документ, открытый по данной форме. В качестве встроенной должны быть обычная вьюшка с отображением иерархии респонсов.

 

[Akupaka]

В св-вах встроенной вьюшки на второй закладке есть галка "Show only current thread"

ух ты! хороший вариант! я как-то его упустил в своей практике...

единственное, как я понял, в этом внедренном виде будет отображаться и головной документ, и от этого не уйти (?), но, если это не помеха, то очень хороший вариант!

 

[masyna]

Большое спасибо очень помогло, но вот возник еще один вопрос!!!!

Как сделать ответный документ сразу к нескольким основным документам одной формы???
Поясню Вообще делаю базу данных учета технических средств, в которой есть основная форма описывающая характеристики одного технического средства. Это основная форма в которой хочу сделать историю ответных документов (накладная, акт перевода в другую категорию, акт списания и т.д.). Так вот как можно сделать Ответный документ (НАКЛАДНАЯ) сразу для нескольких технических средств?????

Еще раз повторюсь, кому не жалко можно образец какой нибудь похожей базы данных!!!

 

[nvyush]

Ответный документ может иметь только одного родителя (ссылка на родителя хранится в поле $REF в особом формате).
Можно сделать псевдо иерархию и хранить в накладной UNIDы техсредств в многозначном текстовом поле. В данном случае не будут работать штатные средства Лотуса по поддержке иерархии (doc.Responses, doc.ParentDocumentUNID), но это решаемо.

Может чем поможет элегантная функция от Egor A. Ivanov; InterTrust 13.03.2007 17:24
на входе псевдодочерний документ, имя поля заменяющего $REF и родительский UNID в строке.

Sub SetRRLItem (note As NotesDocument, itemName As String, itemValue As String)
Dim parent As New NotesDocument (note.ParentDatabase)
Dim response As New NotesDocument (note.ParentDatabase)
Let parent.UniversalID = itemValue
Call response.MakeResponse (parent)
Call response.GetFirstItem ("$REF").CopyItemToDocument (note, itemName)
End Sub

P.S. И не надо так кричать — люди здесь не глухие

 

[Akupaka]

nvy

а можно разъяснения получить по коду? в чем его суть?
я вижу, что в итоге мы получаем как минимум одно поле $REF в note-документе, но для этого достаточно было вызвать метод MakeResponse у соответстующего объекта напрямую, т.е. без этого замысловатого способа.
а если мы получим в note-документе два и более полей $REF, то чего этим добьемся?

 

[turumbay]

а можно разъяснения получить по коду? в чем его суть?
я вижу, что в итоге мы получаем как минимум одно поле $REF в note-документе...

поле $ref в note не создается.
Call response.GetFirstItem ("$REF").CopyItemToDocument (note, itemName)
суть: не нарушая родной иерархии - выстроить альтернативную по другому полю. Тип поля - Response Reference List, т.о. по нему можно строить вьюхи как по $ref

 

[Akupaka]

а слона-то я и не заметил спасибо

суть: не нарушая родной иерархии - выстроить альтернативную по другому полю

а для чего сохранять тип поля (Response Reference List)?
предполагается, что альтернативная иерархия в виде будет по Default строиться?
тогда разве нужен тип RRL?

 

[nvyush]

nvy

а можно разъяснения получить по коду? в чем его суть?
я вижу, что в итоге мы получаем как минимум одно поле $REF в note-документе, но для этого достаточно было вызвать метод MakeResponse у соответстующего объекта напрямую, т.е. без этого замысловатого способа.
а если мы получим в note-документе два и более полей $REF, то чего этим добьемся?

Алгоритм следующий
- создаём временный родительский документ
- задаём ему unid актуального родительского документа
- создаём временный дочерний документ
- создаём в дочернем документе поле $REF к временному родительскому документу. Т.к. у временного родительского документа тот же unid, что и у настоящего, то после завершения кода и удаления временного родительского документа из памяти, данная ссылка будет указывать на настоящего родителя
- копируем поле $REF под нужным именем в настоящий дочерний документ.

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

 

[Akupaka]

Если поля ссылок делать видимыми, они отображаются в виде ссылок на документы

только для этого тип RRL сохраняется?

 

[turumbay]

только для этого тип RRL сохраняется?

это скорее бесплатный довесок.
RRL нужен для default $ref := ...
простого юнида, как мне помница, не хватало

 

[nvyush]

только для этого тип RRL сохраняется?

Если честно, сам я альтернативную иерархию пока нигде не использовал, нужды не было. Наткнулся на любопытный код, взял себе на заметку — может где пригодится. Возник вопрос по теме — я поделился (с указанием авторства). А уж использовать или нет — это каждый для себя сам решает.

 

[TIA]

только для этого тип RRL сохраняется?

Без RRL не будет работать отображение документа во вьюхе как респонс.

 

[Akupaka]

Без RRL не будет работать отображение документа во вьюхе как респонс.

а не напомнишь как это дело в виде организовать? что-то не могу вспомнить

 

[nvyush]

Akupaka
Кажись, в формулу отбора надо добавить что-то типа Field $REF := MyREF;

 

[turumbay]

а не напомнишь как это дело в виде организовать? что-то не могу вспомнить

дять, ну ты-то старый аксакал форума! заюзай посик.
https://codeby.net/threads/32230.html

 

[hosm]

Мы перед селектом вьюхи делали DEFAULT $Ref:=myParent;
Работало, так как в документах $Ref отсутствовало.
С вариантом Field $REF не экспериментировали

 

[Akupaka]

дять, ну ты-то старый аксакал форума! заюзай посик.

дык, не такой уж и старый :discard:
я юзал, и интертраст порыл, и даже по памяти вначале сам написал... но че-то не работает
хочется инструкцию

и вот еще, как мне для одних доков этот дефолт заюзать, а для других нет?
бо дефолт оператором в @IF не фухрычит... или я туплю по полной

Добавлено: вопрос отпал. я все сделал правильно... но!
но TIA прав
тип поля обязательно RRL

и да! код предложеный nvy весьма полезен

к стати, вот, кому интересно очень хороший пример:

Ссылка скрыта от гостей

(ищите вложение внизу страницы)

 

[TIA]

и вот еще, как мне для одних доков этот дефолт заюзать, а для других нет?

Например так. Пишем во View Selection:

FIELD $Ref := @If(@IsAvailable(MyRef) & OtherCondition; MyRef; $Ref);