изменение значений полей в PAI

zIk

на экране при вводе нового значения в поле F1 происходят необходимые расчеты.

Code:

process after input.
  field F1 module F1_change on request.

нужно чтобы при изменении F2 изменялось значение F1 и отрабатывало F1_change

в F2_change: F1 = F2.

работает только такой вариант

Code:

process after input.
  field F2 module F2_change.
  field F1 module F1_change.
  field F2 module F2_change.
  field F1 module F1_change.

остальные вариации (в том числе и с on request, on input) не дают должного результата.
странное решение.

:?:

а можно ли сделать чтобы PAI F2, PBO, PAI F1, PBO ?

John Doe

Вычисления значений поместите в PBO и будет Вам счастье...

sy-uname

zIk написал:

на экране при вводе нового значения в поле F1 происходят необходимые расчеты.

Code:

process after input.
  field F1 module F1_change on request.

нужно чтобы при изменении F2 изменялось значение F1 и отрабатывало F1_change

в F2_change: F1 = F2.

Смотрите оератор chain

Цитата:

работает только такой вариант

Code:

process after input.
  field F2 module F2_change.
  field F1 module F1_change.
  field F2 module F2_change.
  field F1 module F1_change.

остальные вариации (в том числе и с on request, on input) не дают должного результата.
странное решение.

:?:

а можно ли сделать чтобы PAI F2, PBO, PAI F1, PBO ?

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

zIk

Если кто забыл написал(а):

PAI
field ... module ... on input. - срабатывает всегда если значение не initial.
field ... module ... on request. - срабатывает только если значение изменено пользователем.

решить свой вопрос я пробовал так:
в PAI F2 on request - установка флажка FL2 - чтобы затем обработать в PBO.
в PBO - по флажку FL2 меняю значение F1 одним из способов:

F1 = F2.
F1 меняется; PAI-PBO больше не вызывается
F1 = F2.
call function 'SAPGUI_SET_FUNCTIONCODE'.
F1 меняется; PAI-PBO вызывается; PAI инициируется только on input для непустых полей, а on request не инициируется.
call function 'DYNP_VALUES_UPDATE'.
F1 не меняется; PAI-PBO не инициируется
call function 'DYNP_UPDATE_FIELDS'
exporting request = 'B'.
(в dynpfields значение только для F1)
DYNP_UPDATE_FIELDS вылетает на call 'HELP_PUT_FIELD'; F1 меняется; поле F2 заполнено _______;
после Enter-a PAI-PBO только on input; F1 очищается; F2 заполняется изначально введенным значением
call function 'DYNP_UPDATE_FIELDS'
exporting request = 'A'.
(в dynpfields значение только для F1)
F1 не меняется; F1 on request НЕ инициируется, но отрабатывает при первом срабатывании PBO.

Итого РЕШЕНИЕ такое:
в PAI:

Code:

F2 on request - установка флажка FL2 для обработки в PBO (изменение F1).
F1 on request - установка флажка FL1 для обработки в PBO (реакция на изменение F1).

в PBO:

Code:

if FL2 = 'X'. 
  F1 = F2. " чтобы значение в поле появилось
  call function 'DYNP_UPDATE_FIELDS' " чтобы возникло событие on request для F1
    exporting request = 'A'.
   (в dynpfields значение только для F1)
  call function 'SAPGUI_SET_FUNCTIONCODE'. " чтобы PAI-PBO сразу сработало.
endif.

if FL1 = 'X'.
  " реакция на изменение F1
endif.

осталось непонятно:
:?:

что же за параметр request у ФМ DYNP_UPDATE_FIELDS (почему при request = 'B' на экране все заломалось)?
:?:

как и для чего использовать ФМ DYNP_VALUES_UPDATE?

zIk

еще для справки

Code:

* Function modules to update screen

* Doesn't work in value request event
call function 'DYNP_VALUES_UPDATE'

* Doesn't work if the field is read only
call function 'DYNP_UPDATE_FIELDS'

Jelena

Согласна с sy-uname - IMHO как-то небрежно продуман дизайн экрана. Понимаю, если бы поле F1 было input, а F2 просто display (типа в F1 вводим номер поставщика, а в F2 получаем название организации), все понятно. А тут выходит, что у вас оба поля input, но вы в программе почему-то манипулируете их значениями после ввода пользователя. Так очень легко самому запутаться в трех соснах и юзеров запутать. Получается, что вижу и ввожу одно, а потом в программе "перепятушки". А что если оба поля юзер изменит?

Удав

zIk написал:

на экране при вводе нового значения в поле F1 происходят необходимые расчеты.

Code:

process after input.
  field F1 module F1_change on request.

нужно чтобы при изменении F2 изменялось значение F1 и отрабатывало F1_change

в F2_change: F1 = F2.

А не проще ли сделать совместную обработку в PAI?

Code:

CHAIN.
  FIELD: F1, F2.
  MODULE process ON CHAIN-REQUEST.
ENDCHAIN.

Естественно, для анализа лучше хранить старые значения переменных F1 и F2 :wink:

zIk

Jelena написала:

Согласна с sy-uname - IMHO как-то небрежно продуман дизайн экрана. Понимаю, если бы поле F1 было input, а F2 просто display (типа в F1 вводим номер поставщика, а в F2 получаем название организации), все понятно. А тут выходит, что у вас оба поля input, но вы в программе почему-то манипулируете их значениями после ввода пользователя. Так очень легко самому запутаться в трех соснах и юзеров запутать. Получается, что вижу и ввожу одно, а потом в программе "перепятушки". А что если оба поля юзер изменит?

если интересно - Задача изначальная:
В заказе в списке операций (тр IW32) введено самопальное поле "Колво" - используется только для операций добавленных через "добавление ТехКарт" для указания порционности ТехКарт.
Смысл задачи на разработку - когда у одной операции изменяют "Колво" - нужно поменять "Колво" у всех операций из той же ТехКарты.
А при изменении "Колво" - у операции нужно (и уже функционирует) пересчитать "Работа", "Продолжительность",...

Удав написал(а):

А не проще ли сделать совместную обработку в PAI?

Code:

CHAIN.
  FIELD: F1, F2.
  MODULE process ON CHAIN-REQUEST.
ENDCHAIN.

Естественно, для анализа лучше хранить старые значения переменных F1 и F2 :wink:

В рамках исходной "упрощенной задачи" объединять on request в один модуль обработки, а в нем "как-то" определять от кого сюда попали - немного усложнило бы "упрощенную задачу"

Удав

zIk написал:

В рамках исходной "упрощенной задачи" объединять on request в один модуль обработки, а в нем "как-то" определять от кого сюда попали - немного усложнило бы "упрощенную задачу"

Ну да, проще использовать и PAI, и PBO-логику чем просто PAI-логику :lol:

zIk

Удав написал(а):

zIk написал:

В рамках исходной "упрощенной задачи" объединять on request в один модуль обработки, а в нем "как-то" определять от кого сюда попали - немного усложнило бы "упрощенную задачу"

Ну да, проще использовать и PAI, и PBO-логику чем просто PAI-логику :lol:

если это подкол, то:

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

John Doe

Млин... А пацаны то не знают

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

sy-uname

zIk написал:

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

У вас есть отличный шанс разбогатеть - в тысячах стандартных диалоговых транзакциях именно так и делается - в PAI меняется значения полей. Чем не повод к судебным разбирательствам?

Кстати, о кручении PBO-PAI - а что будет если пользователь после ввода значения не нажмёт enter, а захочет сменит таб? Или сразу нажмёт сохранить? Или другой функциональный код? Вы стопроцентно уверены что по завершению PAI начнётся именно PBO текущего экрана?

zIk

John Doe написал:

Млин... А пацаны то не знают

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

с логикой экрана разобрался, вопросы решил. За помощь спасибо

только объясняюсь сумбурно :oops:

zIk

sy-uname написал(а):

zIk написал:

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

У вас есть отличный шанс разбогатеть - в тысячах стандартных диалоговых транзакциях именно так и делается - в PAI меняется значения полей. Чем не повод к судебным разбирательствам?

Начинаю понимать, что мне посоветовали использовать CHAIN - НЕ чтобы один PAI-модуль для ОБРАБОТКИ изменения любого из chain-полей, А для возможности ИЗМЕНЕНИЯ всех chain-полей в этом PAI-модуле.
+ анализ старых значений. о чем уже писал Удав

:oops:

Удав

zIk написал:

в PAI менять значения полей не хорошо

Порадовало

В данном случае может быть имеет смысл поискать user-exit, который отрабатывает в нужном месте?

Правила форума

изменение значений полей в PAI

Кто сейчас на конференции