Проблема такая. Имеется средство поиска, привязанное к полю через AT SELECTION-SCREEN ON VALUE-REQUEST FOR (SELECT-OPTIONS)-LOW.
Средство поиска вызывается через ФМ F4IF_START_VALUE_REQUEST и потом выбираются результаты из результирующей таблицы.
Когда эта схема отрабатывается первый раз, то все красиво садится в первую строчку диапазона, а когда у SELECT-OPTIONS нажимаешь кнопочку "Многократного выбора" и вызываешь справку для второй строки, то событие отрабатывает с ошибкой.
Вопрос, как определить, что справка вызвалась для другой строки SELECT-OPTIONS и как туда вставить результат выбора???
Может такую ситуацию вообще обрабатывать иначе???

Так делать не надо. Просто присваивайте выбранное значение <fs_ret>-fieldval переменной (SELECT-OPTIONS)-LOW. (В Вашем случае)

Согласен. Перемудрил с FIELD-SYMBOLS. Спасибо.

Просто, с параметрами такое прокатывает, а с SELET-OPTIONS получилось, что при вызове справки для последующих строк, после первой, в fieldname - чушь какая-то

а почему не сделать через SELECT-OPTIONS <ваше поле мн.выбора с указанным типом> MATCHCODE OBJECT <имя вашего СП>?

Можно бы и так. И это самый простой способ.
Только в качестве справки у меня вызывается комплексное средство поиска. В котором у меня надо скрывать некоторые поля как на форме задания ограничений, так и в результирующей таблице.

Подобные танцы с бубном я реализовал так:
- блок AT SELECTION-SCREEN ON VALUE-REQUEST FOR...
1) Задаю значения по некоторым полям в средстве поиска
2) через MEMORY ID передаю таблицу типа ddshfprops с указанием полей, которые надо скрыть при выборе и выводе (те самые, по которым я задал первичные значения).

- в обоих средства поиска, что включены в комплексное, я добавил расширение, которое работает так:
1) Принимает и обрабатывает через MEMORY ID табличку типа ddshfprops. То есть, скрывает нужные мне поля.

Почему сделал так?
Если пытаться применить табличку типа ddshfprops к самому комплексному средству поиска, то это не подействует.
В элементарных средствах поиска указанные поля сокрыты не будут.

Может кто предложит более красивый способ решения подобной проблемы?
Проблема просто в том, как указать в ФМ F4IF_START_VALUE_REQUEST, что я хочу скрыть поля не в комплексном СП, а в его элементарных?
В табличке типа ddshfprops нет указания на элементарное СП. Там вообще нет разделения, для кого ты задаешь ограничения, для комплексного или элементарного...

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

Может гуру и меня заодно просветят, почему это нехорошо?

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

Что-то не совсем понимаю, в чем проблема с указанием комплексного СП. Элементарные СП вы же сами сможете отредактировать и перечислить, какие поля вам необходимы. Ограничение значений можно реализовать и не через ракурс, а через свой ФМ для СП.

Суть в чем. Есть 2 элем.СП. Они объединены в комп.СП.
Данные для элем.СП дают ракурсы, объединяющие таблицы по инфотипам HR.
У каждой таблицы инфо-типа м.б. свои временные интервалы (begda-endda).
Чтобы СП вывело нужную тебе запись, следует на экране выбора СП задать эти временные интервалы, а если я хочу, чтобы пользователю вывелась выборка только за определенный период (последняя актуальная запись в каком-то месяце), то следует эти интервалы задать, но поля скрыть (чтобы за другой период не выбрали случайно или специально). Эти поля можно скрыть программно, заполняя список скрываемых полей в таблице типа ddshfprop и передавая её в ФМ F4IF_START_VALUE_REQUEST.
Проблема в том, что у обоих элем.СП есть поля с датами, которые я задаю. Но эти элем.СП объединены в комп.СП и указание полей в таблице типа ddshfprop и передача её в ФМ F4IF_START_VALUE_REQUEST ничего не дают. Поля у элем.СП в комп.СП не скрываются.
Приходится к каждому элем.СП добавлять расширение, в которое через MEMORY ID передается и обрабатывается таблица типа ddshfprop, с указанием списка полей, которые следует скрыть.
Предложения некоторых коллег о создании "нормального" СП в словаре, со всеми заданными ограничениями - невозможны. Это HR таблицы. Тут такое не прокатывает. Останется куча одинаковых записей, но с разными периодами действия. А ограничить можно только через СП.

В общем, где-то так. БукАв, конечно, много...

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

It's up to you what nonsence is. А костыли в том, что вы откидываете стандартные методы(создать средство поиска на базе стандартного и сделать свою обработку), потому что вам кажется, что это дурнее, но при этом пытаетесь сделать что-то, что изменит стандартный, т.е. подпираете конструкцию, чтобы она стояла ровно и в случае с вашей спецификацией.

А почему для своего отчета нельзя создать собственное СП, присвоить его через matchcode object? И при чём здесь HR? Чего я не знаю?
upd. вы ведь создаете свою прогу для сбора данных, она к стандарту не относиться и привязываете её к полю, созданному вами в вашей программе. Это вообще стандарт не задевает никаким боком(HR тоже, т.к. такую выборку можно сделать хоть из PS'a, но надеюсь им это не понадобится).

эти врем.интервалы вы задаете на экране к.средства?