обработка идет в фм для средства поиска в enjoy транзакции (fb60). при помощи DYNP_VALUES_READ можно считать данные из видимой части таблицы.
а как можно получить текущий видимый номер строки для table control, не имея самой ссылки на объект?

А что мешает эту самую ссылку получить?
Через тот же ASSIGN.

я попробовал через assign, но (SAPLFSKB)table-current_line показывает на номер последней видимой на экране строки, в то время как нужен номер строки, на которой находится курсор. как с этим бороться, я вообще там ищу ?

Можно попробовать GET CURSOR, но может не получиться...

Для получения строки внутри экранной таблицы, по идее, должна использоваться конструкция GET CURSOR FIELD field LINE lin.
И если посмотреть код экрана, то легко видеть, что строка сохраняется в подпрограмме get_cursor в глобальной переменной g_cursorline.

sy-uname: да, это правда. после того, как отработает PAI переменная доступна. проблема в том, что при вызове search help эта форма не вызывается. другими словами, если нажимать на поле кнопку enter, тогда будет инициализироваться переменная g_cursorline, а если f4 - то не будет.

EGF: если же вызывать из search help форму get_cursor в той программе либо напрямую - толку не будет, поле не заполнится.

Я говорил не про форму, а про оператор GET CURSOR.

понимаю. я имею в виду то, что

data: g_line type i.
get cursor line g_line.

не работает также как и

perform get_cursor(SAPLFSKB).

в обоих случаях возвращается sy-subrc = 4. что значит, что The cursor is not on one of the list or loop lines. фактически же это к тому, что PAI не отрабатывал.

Попробуйте через ASSIGN получить значение переменных g_cursorline или crs_saveline программы SAPLFSKB - они глобальные, поэтому должно получиться. Однако, имейте в виду, что нажатие F4, как известно, PAI не вызывает, поэтому вы можете получить не ту строку, на которой вызвали средство поиска, а ту, на которой он стоял при вызове средства поиска.

И, кстати, если речь зашла о ФМ DYNP_VALUES_READ. Присмотритесь к ФМ GET_DYNP_VALUE.

EGF: я примерно о том же писал несколько выше. там похоже действительно не отрабатывается PAI и не инициализируются переменные. считать их можно, но толку от этого чуть.
ФМ GET_DYNP_VALUE - по сути обертка над DYNP_VALUES_READ для считывания отдельного значения. если знаешь что считывать и больше ничего не надо - немножко удобней. но не мой случай.

насколько я себе процесс и область исследования представляю, есть презентационная часть, которая отправляет данные приложению при нажатии enter. после того, как данные попадут в приложение, можно будет говорить о том, чтобы считывать их из переменных или из внутренней таблицы, привязанной к гриду. а пока данные приложению не переданы и находятся только в презентации, их можно получить только вызвав какой-то ФМ, забирающий данные с клиента, типа как та сишная функция, которую вызывает DYNP_VALUES_READ. тут два пути - первый: искать функцию на си, которая считает атрибуты грида с презентации, либо каким-то образом при нажатии f4 эмулировать enter для инициации процесса передачи данных приложению, а потом считывать атрибуты из свойств грида.

что скажете?

А Вы пробовали GET_DYNP_VALUE? Не помогло? Или Вы просто предположили, что это не Ваш случай?

EGF: кратко - да, пробовал.
развернуто: GET_DYNP_VALUE не поможет не потому, что плохой, а потому что вызывает DYNP_VALUES_READ, этот ФМ вызывает сишную HELP_GET_FIELDS, которая забирает данные с презентационного грида. она нормально все считывает, единственное что, не говорит, какая у презентационного грида текущая позиция курсора. во время отработки PAI эта позиция как-то передается на сервер приложений. вопрос - как?

Мне показалось, что этот ФМ Вам подойдёт, потому перед вызовом DYNP_VALUES_READ в нём вызывается DYNP_GET_STEPL, а это, кажется то, что нужно. Ну, значит, я ошибся.

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

ну в общем, я пока резюмирую так:
если делать

CALL FUNCTION 'DYNP_GET_STEPL'
IMPORTING
POVSTEPL = wa_row
EXCEPTIONS
STEPL_NOT_FOUND = 1
OTHERS = 2.

или GET CURSOR

в элементарном средстве поиска, включенном в комплексное - будет в первом варианте возвращаться ноль, а во втором - sy-subrc = 4. т.е. определить поле, на котором находится курсор в таблице экрана нельзя. похоже, что это связано с тем, что текущий экран меняется во время вызова КСП и информация, связанная с предыдущим экраном становится недоступной. ведь информация о том, из какого экрана требуется получить данные в фм DYNP_GET_STEPL не передается.

если же использовать в PAI исходного экрана обработчик

PROCESS ON VALUE-REQUEST. "F4
FIELD IT_TEST-KOSTL MODULE help_kostl.

MODULE help_kostl INPUT.

DATA: wa_row LIKE sy-stepl,

CALL FUNCTION 'DYNP_GET_STEPL'
IMPORTING
povstepl = wa_row
EXCEPTIONS
stepl_not_found = 1
OTHERS = 2.

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