ALV_GRID пересчет сумм и модификация ячеек

slim

Здравствуйте коллеги.

Ситуация: Есть два CL_GUI_ALV_GRID при изменении ячейки в одном, мне необходимо поменять значение ячейки в другом. Метод REFRESH_TABLE_DISPLAY не использую т.к. он м моем случае работает медленно. При модификации ячейки GRID1 использую событие DATA_CHANGED и метод ER_DATA_CHANGED->MODIFY_CELL. в этом же событии мне необходимо модифицировать ячейку GRID2, ПЫТАЮСЬ сделать это следующим образом, НО ЧТО-ТО НЕ ПОЛУЧАЕТСЯ:

Code:

       DATA : LO_CHANGE TYPE REF TO CL_ALV_CHANGED_DATA_PROTOCOL,
              LV_TABLE TYPE REF TO DATA,
              MODI_CELL TYPE LVC_S_MODI,
              DD TYPE LVC_T_MSG1.

       FIELD-SYMBOLS : <LT_FS> TYPE STANDARD TABLE.
       
       CREATE OBJECT LO_CHANGE EXPORTING I_CALLING_ALV = GO_GRID2.
       CREATE DATA LO_CHANGE->MP_MOD_ROWS LIKE <GT_LVC_OUTTAB2>.
       ASSIGN LO_CHANGE->MP_MOD_ROWS->* TO <LT_FS>.
       APPEND <LS_TAB1> TO <LT_FS>.
       LO_CHANGE->MT_ROID_FRONT = ER_DATA_CHANGED->MT_ROID_FRONT.
       LO_CHANGE->MT_FIELDCATALOG = GT_FIELDCAT2.
       LO_CHANGE->MODIFY_CELL( EXPORTING I_ROW_ID    = LS_GOOD-ROW_ID
                                         I_TABIX     = LS_GOOD-TABIX
                                         I_FIELDNAME = 'ZRMEND'
                                         I_VALUE     = <LV_OST_END> ).
       LO_CHANGE->MODIFY_PROTOCOL_ENTRY( EXPORTING IT_MSG = DD  ).
       LO_CHANGE->FREE( ).

Вопрос 1 : что я делаю не так или каким образом возможно изменить 1 ячейку GRID2 из события DATA_CHANGED GRID1.
Вопрос 2 : каким образом можно заставить CL_GUI_ALV_GRID пересчитывать суммы после каждого ввода(без метода REFRESH_TABLE_DISPLAY )

Заранее спасибо.

John Doe

slim написал(а):

Метод REFRESH_TABLE_DISPLAY не использую т.к. он м моем случае работает медленно.

Вы работаете на 486DX2 процессоре?

slim

John Doe написал:

slim написал(а):

Метод REFRESH_TABLE_DISPLAY не использую т.к. он м моем случае работает медленно.

Вы работаете на 486DX2 процессоре?

В любом случае должна быть какая-нибудь альтернатива REFRESH_TABLE_DISPLAY... для того чтобы изменить значение ячеек в GRID1 и GRID2 из GRID1, и пересчитать суммы только по 1 столбцу.

Если кто-нибудь сможет мне подсказать буду очень благодарен.

Besa

Альтернатива - выйти из программы и зайти заново. Но это Вас не устроит, не думаю что есть какие то способы обновить АЛВ быстрее чем это сделает метод REFRESH_TABLE_DISPLAY.

slim

По ходу работы появилась еще одна проблема... ALV съедает всю память ПК по мере ввода в него данных.

Каким образом можно это вылечить?

Заранее спасибо.

Besa

slim написал(а):

По ходу работы появилась еще одна проблема... ALV съедает всю память ПК по мере ввода в него данных.

Каким образом можно это вылечить?

Заранее спасибо.

http://www.sapboard.ru/forum/viewtopic ... 4&start=15 ...

slim

Besa написал:

slim написал(а):

По ходу работы появилась еще одна проблема... ALV съедает всю память ПК по мере ввода в него данных.
Каким образом можно это вылечить?
Заранее спасибо.

http://www.sapboard.ru/forum/viewtopic ... 4&start=15 ...

Нет, я наверно не правильно объяснил, у меня заканчивается память не сервера приложений а оперативная память ПК у пользователя. Табличка моя не большая, всего 100x50, данные ввожу типа P. При вводе данных запускаю диспетчер задач и смотрю, что при каждом нововведенном значении увеличивается занимаемая память процесса saplogon.exe. Когда оперативная память заканчивается у меня вылетает дамп на ФМ flush(при вызове его самой системой).

Еще хочу добавить, что в основном всю память ест метод REFRESH_TABLE_DISPLAY, если делаю ER_DATA_CHANGED->MODIFY_CELL все работает гораздо быстрее и не забивает память. Из этого можно сделать вывод, что при REFRESH вся наша(визуальная) табличка скидывается в оперативную память ПК(не сервера приложений) и так до тех пора пока эта память не закончиться.

Следовательно возникают вопросы:
1. Возможно не очень корректно, но все же, можно ли как-нибудь очищать память выделяемую под процесс saplogon.exe из ABAP программы?
2. Как пересчитать суммы только по 1 столбцу без REFRESH_TABLE_DISPLAY?

Заранее спасибо!!!

Кодер

2 slim: наблюдал похожую проблему. Решилось установкой более нового патча на SAPgui. Попробуйте.

slim

Кодер написал(а):

2 slim: наблюдал похожую проблему. Решилось установкой более нового патча на SAPgui. Попробуйте.

Спасибо огромное

именно это и помогло, у меня был SAP logon 710 патч 11, установил патч 14 и все заработало.

Бородин Игорь

Была такая же проблема, с переполнением памяти, последний патч-левел все исправил.

Однако, если в гриде несколько тысяч строк и для нахождения доп. информации по строке будем рефрешить весь грид, то даже при "плавном" обновлении:

Code:

stable-row = 'X'. 
stable-col = 'X'. 
CALL METHOD grid->refresh_table_display( is_stable = stable )) 

будет неприятное передергивание всего экрана, даже на мощном компе. Поэтому, правильнее делать нахождение зависимых полей в событии data_changed грида.
Вот пример (при вводе табельного номера, подтягивается ФИО):

Code:

  METHOD handle_data_changed.

    DATA:
      ls_good_cell      TYPE lvc_s_modi,
      l_subrc           TYPE sysubrc,
      l_msg_dummy       TYPE char1,
      l_zzpernr_txt     TYPE char1024.
    FIELD-SYMBOLS:
      <mod_cell>        TYPE lvc_s_modi.


*   обработка изменений ячеек
    LOOP AT er_data_changed->mt_good_cells INTO ls_good_cell.

      READ TABLE er_data_changed->mt_mod_cells ASSIGNING <mod_cell>
            WITH KEY row_id    = ls_good_cell-row_id
                     fieldname = ls_good_cell-fieldname.

      CASE ls_good_cell-fieldname.
        WHEN 'BDATU'.
*         .....

        WHEN 'ZZPERNR'.
*         при изменении табельного номера (ZZPERNR), подтягиваем ФИО (ZZPERNR_TXT)
          PERFORM get_zzpernr_txt USING    ls_good_cell-value
                                  CHANGING l_zzpernr_txt
                                           l_subrc.
          CALL METHOD er_data_changed->modify_cell
            EXPORTING
              i_row_id    = ls_good_cell-row_id
              i_tabix     = space
              i_fieldname = 'ZZPERNR_TXT'
              i_value     = l_zzpernr_txt.

          IF  l_subrc NE 0
          AND ls_good_cell-value NE '00000000'.
            <mod_cell>-error = 'X'.
            MESSAGE e001(00) WITH 'Табельный №' ls_good_cell-value 'не существует' INTO l_msg_dummy.
          ENDIF.

      ENDCASE.

      CHECK <mod_cell>-error NE space.

*     добавляем сообщение в лог
      CALL METHOD er_data_changed->add_protocol_entry
        EXPORTING
          i_msgid     = sy-msgid
          i_msgty     = sy-msgty
          i_msgno     = sy-msgno
          i_msgv1     = sy-msgv1
          i_msgv2     = sy-msgv2
          i_msgv3     = sy-msgv3
          i_msgv4     = sy-msgv4
          i_fieldname = ls_good_cell-fieldname
          i_row_id    = ls_good_cell-row_id
          i_tabix     = space.
    ENDLOOP.

  ENDMETHOD.                    "handle_data_changed

Удав

Бородин Игорь написал(а):

Была такая же проблема, с переполнением памяти, последний патч-левел все исправил.

Однако, если в гриде несколько тысяч строк и для нахождения доп. информации по строке будем рефрешить весь грид, то даже при "плавном" обновлении:

Code:

stable-row = 'X'. 
stable-col = 'X'. 
CALL METHOD grid->refresh_table_display( is_stable = stable )) 

будет неприятное передергивание всего экрана, даже на мощном компе. Поэтому, правильнее делать нахождение зависимых полей в событии data_changed грида.
Вот пример (при вводе табельного номера, подтягивается ФИО):
[/code]

Мда..организовывать ввод данных в ALV с большИм количеством данных - вы не находите, что это сам по себе неправильный подход для R/3?

slim

Спасибо за ответы

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

Мда..организовывать ввод данных в ALV с большИм количеством данных - вы не находите, что это сам по себе неправильный подход для R/3?

А если есть такая необходимость, какие есть альтернативы? На экранных таблицах делать не очень красиво.
Темболее в ALV с большим объемом данных не обязательно же вводить все поля. Просто разработчик предоставляет быстрое и удобное изменение данных.

Свои проблемы решил:
1. Обновление ячейки grid1 из data_chenge grid1 реализовал аналогично как "Бородин Игорь"
2. Обновление ячейки grid2 из data_chenge grid1

Code:

        REFRESH LT_MODI.
        LS_MODI-ROW_ID = LS_GOOD-ROW_ID.
        LS_MODI-FIELDNAME = 'ZRMEND'.
        LS_MODI-VALUE = <LV_OST_END>.
        APPEND LS_MODI TO LT_MODI.

        GO_GRID2->CHANGE_DATA_FROM_INSIDE( EXPORTING  IT_STYLE_CELLS  = LT_MODI
                                           IMPORTING  ET_BAD_CELLS    = LT_MODI_IM
                                                      ET_MSG          = LT_MSG_IM ).

Удав

Цитата:

А если есть такая необходимость, какие есть альтернативы?

В чем заключается необходимость выбирать кучу данных, чтобы редактировать одну строку?
Для выбора нужного документа существует понятие "Средство поиска". :rtfm:

Цитата:

На экранных таблицах делать не очень красиво.

Зато быстродействие намного выше и нет проблем с памятью.

Цитата:

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

особенно понравилось "быстрое"

Бородин Игорь

Цитата:

В чем заключается необходимость выбирать кучу данных, чтобы редактировать одну строку?

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

Удав

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

Ну и пользователей нужно обучать заполнять критерии выбора на 1-м экране.

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

ALV_GRID пересчет сумм и модификация ячеек

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