LookUp

[art]

Подскажите, пожалуйста!

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

[AlGol]

Фильтр накладывается при наличии relation между таблицами, в котором эти два поля задействованы. Пример: таблица WMSPallet.

НО. вопрос в том, что должно быть, если в первом (соседнем) поле пусто. При наличии relation система выведет только записи у которых поле группы пустое. Если же надо чтобы фильтр в этом случае не накладывался, то есть вариант нарисования собственной формы lookupа и наложение нужных фильтров из методов формы.

[art]

2-ое поле может быть выбранным только после заполнения 1-ого, но, не смотря на наличие relation между этими таблицами, оно не работает и это, наверное, правильно, т. к. relation начинает работать тогда, когда открыта первая таблица (родитель), а в моем случае обе таблицы закрыты, а вибираються только Id их записей и заполняются в третью. Возможно, необходимо создать relation для этой третьей таблице???

[AlGol]

Я вот уже совсем ничего не понимаю....

[art]

Есть строка в таблице в которую необходимо заполнить последовательно -
сначало ID группы в первый столбец, затем следующее поле этой строки нужно заполнить ID члена принадлежащего к этой группе, но при появлении LOOKUP-а для выбора членов группы он должен вывести только строки группы выбранной в первом поле.
Группы и члены групп находяться в разных таблицах и имеют между собой relation.

[AlGol]

Мдаас.... Пора объясниться по терминологии, а то названия типа "первая таблица" и пр. нас далеко заведут.

Берем конкретный пример, который я уже указал выше: таблица WMSPallet.
В таблице заполняются поля InventLocationId и wmsLocationId.
Между таблицами WMSPallet и InventLocation есть связь по расширенному типу данных InventLocationId, поэтому мы можем спокойно выбирать склад для паллеты.
Между таблицами WMSLocation и InventLocation есть точно такая же связь, которая позволяет выбрать склад для каждой паллеты.
А вот между таблицами WMSPallet и WMSLocation связь сделана в виде relation на таблице WMSPAllet в котором задействованы поля InventLocationId и WMSLocationId. Поэтому при выборе кода ячейки для паллеты, в lookup выводится отфильтрованный список (фильтрация по коду склада, выбранного в поле WMSPallet.InventLocationId).

Насколько я понял - этого нам и надо было...

[Dron AKA andy]

В данном случае relations между таблицами ни на что не влияют, т.к. системе, открывающей lookup на каком-либо поле таблицы, совершенно наплевать на содержимое других полей этой таблицы. Но ее (систему) можно переубедить , для чего нужно перекрыть метод lookup(), в нем использовать класс SysTableLookup, у которого изменить Query и т.д. Пример: таблица WMSLocation метод lookupLocationId()

[AlGol]

Слона-то я и не увидел! Действительно, при выборе ячейки всегда вызывается форма WMSLocationIdLookup в которой обрабатывается контекст вызова, примерчик приведен не очень корректный

НО! Relation между таблицами действуют так, как я написал выше. Надо только, чтобы связи типа у поля в котором мы делаем выбор, не перекрывали связи таблицы.

[art]

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

[AlGol]

Приложен примерчик в котором нет ни одной строки кода и при этом, при выборе значения в поле tst_List.elementId значения фильтруются по полю tst_List.groupId.

[Dron AKA andy]

Сорри, был неправ, поторопился с ответом! Relations forever!

[art]

Я не совсем понял фразу - "Надо только, чтобы связи типа у поля в котором мы делаем выбор, не перекрывали связи таблицы." если можно поподробнее.
И зачем сделан тип tst_elementIdLookup в примере, или это какраз то, о чем говорит эта фраза????????

[art]

Все, спасибо, я все понял, вся фишка в отсутствии релейшина типа поля tst_elementId, а tst_elementIdLookup не нужен, он только путает, и без него все работает.

[ta_and]

НО!
Есть одно но!
В результате таких манипуляций со связями нарушается стандартное поведение Аксапты.
При таком программировании нельзя будет перейти к основной таблице для ее редактирования! (ctrl-Alt-F4)
Это происходит потому, что типы данных определенных для полей в таблице List не ссылаются напрямую на нужные поля в таблицах-справочниках. А для поля GroupId вообще появляется неоднозначность связывания (по типу поля - с таблицей групп, по релейшну - с таблицей елементов) и неизвестно как еще это все отразится при дальнейшей работе.

Вывод.
Так программировать НЕЛЬЗЯ.
Лучше уж переопределить lookup()чик
Тем более что там кода надо написать всего 10 строк. а может и меньше.
И стандартный функционал останется и задача будет решена.

[Maxim Gorbunov]

Ну, перепрограммировать и переход к основной таблице можно

А вообще, это была скорее "демонстрация мышц". Поддерживаю ta_and: лучше перепрограммировать lookup.

[art]

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

[Maxim Gorbunov]

Заметьте, что при использовании типов и связей объем исправлений несколько возрастает (даже, скорее, не объем, а "география" исправлений ). Все же аккуратней добавить маленький метод lookup с соответствующими комментариями.