Reference group & Edit метод. Не могу сообразить, как правильно сделать (

[kitty]

Есть запись о поставщике.
Нужно дать возможность показать на форме поставщика несколько полей из записи DirParty таблицы . Эта DirParty запись - не та стандартная, на которую в ax ссылается party поле у поставщика , а связанна в данном нашем случае. с поставщиком иначе, через отдельную таблицу связей. То есть, поля как такового на vendTable для связи нет.
По требованию на карточке постащика должно быть показано 3 поля с этой DirParty записи , одно из которых - PartyName нужно иметь возможность редактировать и, таким образом, пользователь будет изменять связь в таблице связей между VendTable и DirParty. При его изменении значения в оставщихся двух полях тоже должны автоматически измениться(подтянуться соответствующие).
То есть, по сути для partyName - edit метод мог бы быть сделан на vendTable. Тогда при открытии формы поставщика значение бы текущее вычислялось и показывалось.,Пользователь потом мог б выбрать новое значение руками, и в этот момент связи между vendTable и dirParty через edit метод менялись бы.......Но.... тк мы говорим о DirParty, то lookup для Namе по сути должен быть сделан с помощью reference group, основанной на EDT DirPartyRecId(unbound с данном случае, тк поля на vendTable нет). И вот тут я уже не понимаю, как правильно совместить edit метод на таблице с refrerence group на форме? Как его указать в свойствах reference group ( там можно только поля, а не методы на таблицу выбирать из списка в referenceField)

Я пока вижу как решение только:
1) инициализировать значения твех оговоренных полей в Active() методе на VendTable DS формы.
2) в методе modified () у reference group.Обрабатывать изменение значения DirPartyRecId

Но таким образом теряется стройность и красота присваивания значения, как было бы, если все выполнялось в одном edit методе ..... поэтому я не уверена, что 1)-2) это - правильный подход
Подскажите, пожалуйста, как правильно реализовать описанное требование?

[Товарищ ♂uatr]

Вы пишите "unbound" поле, как же это так, когда у Вас есть таблица ссылок - её и используйте, приджоините её к форме. Это уже решит половину Ваших проблем, исходя из этого можно вполне ограничиться перекрытием логики update метода.
То, что Вы планируете сделать весьма трудное в дальнейшей поддержке решение.

[kitty]

Джойн простым там не получится, к сожалению, поэтому не могу рассматривать это решение.
В чем предполагаемая сложность поддержки?

[S.Kuskov]

Если логика джойна сложная, а источник данных очень нужен, то можно сделать закат солнца вручную. При активации записи в ведущей таблице вычислять RecId связанной и устанавливать фильтр в Range. Этакая замена delayed связи/
Либо вообще заполнять временную таблицу нужными данными и отображать её вместо постоянной.
Такие вещи лучше делать по нажатию кнопки, с отображением результата на отдельной форме.

[ax_mct]

Цитата:

Сообщение от kitty

То есть, по сути для partyName - edit метод мог бы быть сделан на vendTable. Тогда при открытии формы поставщика значение бы текущее вычислялось и показывалось.
...
Подскажите, пожалуйста, как правильно реализовать описанное требование?

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

Имея свой недавнюю работу с Edit методом на строках sales line, где альтернативных решений вроде бы и не было, жалею об этом. Вроде бы и в PROD уже больше года, но в топку все эти Edit методы. Убивает дебаг, убивает производильность.

Display методы и отдельная кнопка для вызова формы редактирования боковой таблицы 1:1 (AccountNum:AccountNum).
Как раз на днях сделал для формы CustTable.
При этом вначале сделал все "по уму" с Edit методом, но потом переделал.

C Edit производительность редактирования была никакая. Как не кэшировал лучше не стало. Отчасти из-за того что таблица крайне тяжелая, 230 полей, и требует 51KB буфера.
Также очень не хотел добавлять datasource и присоединяться, если можно обойтись без этого. Так как размер буфера.

Поэтому надо не красивее, а проще. Пользователя больше волнует скорость и удобство чему отдельная кнопка для вызова редактируемой формы не мешает.
Это более user friendly чем зависания Edit и гораздо легче в поддержке и расширении.