Добрый день, гуру ABAP'а.

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

Заранее большое спасибо (:

Svirinstel Зачем? ну зачем вам этот пережиток прошлого? Сделайте нормальный протектед метод и наслаждайтесь прелестями ООП!

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

Вместо того, чтобы для каждой кнопки прописывать (и то, в данном примере только 3 поля заполнено):

Если же делать отдельный протектед, то еще придется передавать дополнительно ссылку на таблицу mt_toolbar[], а это еще одни доп параметр при обращении.

Основная идея глобального макроса в этом случае - не загромождать код.

Svirinstel: загромождение кода при макросе примерно то же что и при сокращенной записи вызова метода. Преимущества у макроса только одно: он побыстрее вызова метода(при поставленной задаче этот плюс не критичен). Зато в наличии масса минусов(не отладить, часто непонятен принцип, не наглядная синт.проверка). Передавать ссылку на таблу необязательно, если речь идет о табле-свойстве объекта. Метод - вот наш выбор в ООП.

Для глобальных макросов есть таблица TRMAC.
А в остальном Кодер прав - лучше использовать методы.

Тоже иногда сталкиваюсь с такой задачей. У макросов есть свои плюсы!
Правильным решением считаю исключительно вызов метода в макросе, тогда и отладка доступна.

в 740 можно отладить макрос в виде байткода,
интересно, кто-нибудь этим пользуется?

в целом ,в 740 наконец-то много полезных нововведений для нашего брата.
и сестёр.

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

Табла стандартная объекта e_object, который подается на вход метода TABLE_HANDLE_TOOLBAR, определенного на событие TOOLBAR класса CL_GUI_ALV_GRID. Поэтому я пока что плохо понимаю, как можно из него сделать вызов метода для добавления каждой кнопки без передачи таблы или, как вариант, самого объекта. Атрибут M_CL_TOOLBAR у CL_GUI_ALV_GRID протектед...

Удав под "глобальным" имелось ввиду объявление в глобальном классе, немного не так выразился. Но отдельное спасибо за инфу про TRMAC.
Я знаю, что вообще в классе есть возможность объявления макроса, который будет виден для всех методов (Перейти К->Локальные определения/реализации->Макросы), но проблема в том, что он не наследуется в дочерних.

trop как раз потихоньку прощупываю все прелести 740 ^^

Как только Вы объявите макрос (глобально или даже внутри метода), он станет доступным для любого кода ниже по тексту. Т.е. объявите макрос до его использования в каком-либо из классов - и он будет доступен и из родительского класса, и из дочернего. Правда, он будет доступен и из любого другого класса (ил подпрограммы), который по тексту ниже его .

А, речь о se24. Киньте макрос в общий (для дочернего и базового класса) инклуд или пул типов.

Для работы с тулбаром есть событие TOOLBAR.

так я и написал про метод TABLE_HANDLE_TOOLBAR, который висит на этом событии. Как раз в этом методе я и делаю определение нескольких кнопок в родительском классе, а остальные хотелось бы добавлять в дочернем.


похоже, что это единственный способ, который остается... =/

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

Пул типов работает, достаточно его включить в список пулов предка.