ABAP - Module Pool - ABAP Tips

Sumário
Module Pool.................................................................................................................................5
Programa de diálogo....................................................................................................................5
Estrutura de um programa de diálogo.....................................................................................6
Transferência de campos de dados..........................................................................................7
Atributos de campo..................................................................................................................7
Erro de diálogo.........................................................................................................................7
Consistência de dados..............................................................................................................8
Transação de exemplo.............................................................................................................8
Dynpro....................................................................................................................................10
Característica da tela..............................................................................................................11
Tipo de tela.........................................................................................................................11
Configurações.....................................................................................................................13
Outros atributos.................................................................................................................15
Lista de Elementos.................................................................................................................16
Screen Painter........................................................................................................................17
Palheta de Elementos.........................................................................................................18
Campos de tela.......................................................................................................................24
Lógica de Processamento.......................................................................................................26
Processamento de telas.........................................................................................................28
Ações do usuário na tela........................................................................................................28
Preenchimento de campos de entrada..............................................................................28
Disparando o evento PAI....................................................................................................28
Processamento de campos de entrada/saída.....................................................................29
Campos de programas locais..............................................................................................30
Campos de tela com referência ao Dicionário....................................................................31
Botões na tela....................................................................................................................35
Campo de seleção e botões de radio com código de função..............................................38
Status GUI..............................................................................................................................40
Teclas de função e código de função especiais..................................................................41
Teclas de funções reservadas.............................................................................................41
Teclas de função para a barra de ferramentas padrão.......................................................42
A tecla ENTER.....................................................................................................................42
Definindo o Status GUI.......................................................................................................42
Chamar módulos de diálogo ABAP.........................................................................................45
Chamadas de módulos simples..........................................................................................45
Ajuda de pesquisa..............................................................................................................48
Ajuda de pesquisa no módulo de diálogo...........................................................................48
Caixa de Listagem...............................................................................................................49
Alterar as propriedades da tela dinamicamente....................................................................56
Definindo os atributos dinamicamente..............................................................................56
A tabela SCREEN.................................................................................................................56
ACTIVE, INPUT, OUTPUT, e INVISIBLE.................................................................................57
REQUIRED...........................................................................................................................59
DISPLAY_3D........................................................................................................................59
VALUE_HELP.......................................................................................................................59
INTENSIFIED........................................................................................................................59
LENGTH..............................................................................................................................60
REQUEST............................................................................................................................60
Subtelas..................................................................................................................................64
Definindo a área de subtela na tela principal.....................................................................65
Criar a subtela....................................................................................................................65
Associar a subtela na área de subtela................................................................................66
Controle de Fichas..................................................................................................................70
Definindo a área do controle de fichas e os títulos das abas..............................................70
Atribuindo uma área de subtela a uma aba.......................................................................71
Table Control..........................................................................................................................77
Utilizando o comando LOOP...............................................................................................77
Transferência de valores entre a tela e o programa ABAP.................................................82
Criação do programa ZCADMAT.................................................................................................84
Criação das Includes...................................................................................................................86
Criação da tela 100.....................................................................................................................90
Adicionando elementos na tela 100.......................................................................................92
Criar campo texto – LFA1-LIFNR.........................................................................................94
Criar campo de entrada/saída – LFA1-LIFNR......................................................................95
Criar campo de entrada/saída – LFA1-NAME1...................................................................95
Criar Botão – PB_ABRIR_100..............................................................................................96
Finalização da tela 100...........................................................................................................96
Criação dos elementos da tela 100 no ABAP..........................................................................97
Criação do STATUS GUI para a tela 100..................................................................................97
Criação do TITLE GUI para a tela 100......................................................................................99
Codificação da Lógica de Processamento da tela 100..........................................................100
Codificação do evento PAI................................................................................................103
Criação das transações.........................................................................................................109
Criação da tela 200...................................................................................................................111
Definição do Status GUI........................................................................................................114
Criação do Status GUI.......................................................................................................114
Definição do Title GUI..........................................................................................................118
Associação do Status GUI e Title GUI na tela 200.................................................................118
Tratamento dos códigos de função no evento PAI – Tela 200..............................................119
Adicionando elementos na tela 200.....................................................................................120
Campos de entrada/saída e Campo texto........................................................................121
Controle de Fichas............................................................................................................121
Botão................................................................................................................................124
Criar os objetos correspondentes aos elementos da tela no ABAP......................................125
Codificação do Controle de Fichas na lógica de processamento e no ABAP.........................125
Criação das subtelas do Controle de Ficha...............................................................................129
Criação da subtela 210.........................................................................................................129
Adicionando elementos na subtela 210...............................................................................130
Finalização da tela 210.........................................................................................................131
Criação da subtela 220.........................................................................................................131
Adicionando elementos na subtela 220...............................................................................132
Finalização da tela 220.........................................................................................................133
Criação dos elementos das subtelas no ABAP......................................................................133
Criação da tela 300...................................................................................................................135
Definição do Status GUI........................................................................................................136
Criação dos Códigos de Função na barra de botões.........................................................137
Criação do TITLE GUI para a tela 300....................................................................................138
Associação do Status GUI e Title GUI na tela 300.................................................................139
Tratamento dos códigos de função no evento PAI – Tela 300..............................................139
TABLE CONTROL de materiais..............................................................................................140
Preparação para a criação do Table Control.....................................................................140
Criação da table control...................................................................................................141
Declaração da table control no ABAP (Include TOP)........................................................146
Codificação da lógica de processamento da tela 300.......................................................146
Criação dos botões de funcionalidades da Table Control.....................................................148
Tratamento dos códigos de função da Table Control – Tela 300..........................................149
Validação dos campos da table control................................................................................151
Validação do campo TI_MATERIAL-MATNR.....................................................................153
Validação do campo TI_MATERIAL-MTART......................................................................154
Validação do campo TI_MATERIAL-MBRSH......................................................................155
Validação do campo TI_MATERIAL-MEINS.......................................................................156
Alterar os atributos dos elementos de tela em tempo de execução........................................157
Alteração dos atributos dos elementos da subtela 210.......................................................159
Alteração dos atributos dos elementos da subtela 220.......................................................160
Alteração dos atributos dos elementos da tela 300.............................................................162
Salvar os dados de materiais do fornecedor............................................................................164
Module Pool
Programa de diálogo
Em um programa de diálogo, o sistema apresenta uma tela na qual o usuário pode entrar ou
solicitar uma informação. Como uma reação a entrada ou solicitação do usuário, o programa
executa a ação apropriada: abre a próxima tela, apresenta os dados ou modifica uma tabela do
banco de dados.
Exemplo
Um vendedor pretende realizar uma venda de um determinado material. Na criação do

documento de vendas, o vendedor insere o código do material em um campo específico da
tela. O sistema irá confirmar o material desejado, isto é, o vendedor poderá realizar a venda
do material se o mesmo estiver disponível, caso contrário, o sistema irá retornar uma
informação da indisponibilidade do material.
Para atender tal requerimento, o programa de diálogo deve fornecer:

 Uma interface amigável ao usuário
 Verificação de formato e consistência dos dados entrados pelo usuário
 Fácil correção dos dados digitados
 Acesso aos dados, armazenando-os no banco de dados
O ABAP/4 fornece uma variedade de ferramentas e elementos de idioma para atender os

requerimentos mencionados acima no programa de diálogo.
5
Estrutura de um programa de diálogo
Um programa de diálogo é consistido dos seguintes componentes básicos:
Module
100 Module
Continua na
tela 200 200
300 Module
Continua na
tela 300
Lógica de
Processamento Module
da tela
Dynpro
Module Pool
 Telas (dynpros)
Cada diálogo em um sistema SAP é controlado pelos dynpros. Um dynpro (DYnamic

PROgram) é consistido de uma tela e seu fluxo lógico de processamento o qual controla a
sequência da tela. A lógica de processamento, determina qual processamento ocorre antes
de apresentar a tela (PBO – Process Before Output) e após o recebimento dos dados
inseridos pelo usuário na tela (PAI – Process After Input).
O leiaute da tela fixado no Screen Painter, determina a posição dos campos de

entrada/saída, elementos de texto e elementos gráficos tais como botões de rádio e caixa
de seleção, além que o Menu Painter permite o armazenamento de menus, ícones, botões
e códigos de função em um ou mais Status Gui. Dynpros e Status GUI são responsáveis nos
programas ABAP, pela sequência dos Status GUI e telas em tempo de execução.
 ABAP/4 Module Pool
Cada tela refere-se exatamente a um programa de diálogo ABAP/4. Tal programa de

diálogo é também chamado de module pool, uma vez que consiste de módulos interativos.
A lógica de processamento de uma tela contém chamadas de módulos de um module pool
correspondente. Módulos interativos chamados no evento PBO são utilizados para
preparar o modelo da tela de acordo com o contexto, por exemplo, na inserção de valor
em um campo ou ocultar campos que não são necessários. Os módulos interativos
6
chamados no evento PAI, são utilizados para verificar os dados inseridos pelo usuário e
para ativar as medidas adequadas de diálogo, como a tarefa de atualização.
Todas as telas para serem carregadas de uma transação referem-se a um module pool em
comum. As telas de um module pool são numeradas. Por padrão, o sistema armazena para
cada tela, a tela seguinte a ser apresentada. Esta sequência de tela ou cadeia pode ser
linear, bem como cíclica. Dentro de uma cadeia de tela, uma outra cadeia de tela pode ser
chamada e depois de processá-la, retornar à cadeia original.
Transferência de campos de dados
Como apresentar os campos conhecidos no módulo ABAP/4 na tela? Como transferir as

entradas do usuário da tela para o módulo ABAP? Em contraste com a programação de um
programa do tipo Report, não é possível transferir os dados para a tela através do
comando WRITE. Ao invés disso, o sistema transfere os dados comparando os nomes dos
campos da tela com os nomes das variáveis ABAP/4. Se os dois nomes são iguais, o sistema
transfere os valores dos campos da tela para as variáveis do ABAP/4 e vice-versa. Isto
acontece imediatamente antes e imediatamente após a apresentação da tela.
Atributos de campo
Para todos os campos de uma tela, os atributos de campo são definidos no Screen Painter.
Se o nome do campo na tela corresponde ao nome de um campo do dicionário ABAP, o
sistema automaticamente estabelece uma referência entre esses dois campos. Portanto,
uma grande quantidade de atributos de campos em uma tela é automaticamente copiada
do dicionário ABAP. Os atributos de campo, juntamente com o elemento de dados e
domínio do campo referenciado do dicionário ABAP, formam a base para as funções
padrão para a execução da tela em um diálogo (verificação automática de formato,
verificação de intervalo de valores automático, ajuda de pesquisa, etc).
Erro de diálogo
Outra tarefa do processador de tela é conduzir as mensagens de erro. A verificação de

dados digitados é realizada automaticamente utilizando tabelas de verificação do
dicionário ABAP ou pelo próprio programa ABAP. O processador de tela inclui a mensagem
de erro na tela recebida e devolve a tela ao usuário. A mensagem pode ser sensível ao
contexto, isto é, o sistema substitui espaços no texto da mensagem com o conteúdo do
campo corrente. Além disso, os únicos campos, cujo conteúdo está relacionado com o erro
e para o qual a correção pode resolver o erro, pode aceitar a entrada de dados.
7
Consistência de dados
Para manter os dados consistentes em aplicações complexas, o ABAP/4 oferece técnicas

para otimizar as atualizações do banco de dados que operam independen-temente do
banco de dados subjacente e correspondem às solicitações especiais de programação de
diálogo.
Transação de exemplo
A transação TZ10 (classe de desenvolvimento SDWA) é fornecida com o sistema. Esta

transação consiste de uma tela. O usuário pode entrar com o número de identificação da
empresa aérea e o número do vôo para obter a informação do vôo:
Se o usuário clicar no botão Exibir, o sistema obtém os dados solicitados do banco de

dados e o apresenta:
8
9
Dynpro
Cada tela contém campos utilizados para apresentar a informação solicitada. Os campos
podem ser elemento de texto, campo de entrada e saída, botões de rádio, caixa de seleção
ou botão. A tela da transação TZ10, contém somente elemento de texto e campos de
entrada e saída.
Uma tela SAP é composta por vários componentes:

 Lógica de processamento: Chamada dos módulos de ABAP/4 para a tela.
 Leiaute da tela: Posição dos textos, campos e botões para a tela.
 Atributos de tela: Número da tela, número da tela subseqüente e outros.
 Atributo de campo: Definição dos atributos dos campos individuais na tela.
Atributos
Característica Leiaute de campo Lógica do Processamento
Screen Painter
A criação e edição de todos os componentes de uma tela são realizadas no Screen Painter.
Para abrir o Screen Painter, é necessário criar uma nova tela no Object Browser ou dar um
duplo clique em uma tela existente. O Object Browser abre o Screen Painter. Lá, é possível
entrar a lógica de processamento da nova tela. Pressionando o botão correspondente, é
possível definir os atributos da tela, o qual é uma parte do editor ou é possível escolher o
botão Lista de elementos e alterar os atributos dos campos.
10
Característica da tela
Na opção
“Características” , é
possível definir o tipo de
tela, a tela seguinte a ser
carregada na seqüência,
o posicio-namento do
cursor e a área útil para
a aloca-ção dos objetos
na tela.
Tipo de tela
As telas podem ser Normal, Subtela ou Caixa de diálogo modal.
 Tela Normal
A tela normal tem como característica ser apresentada ocupando toda a área
da tela do SAPlogon, possui título e barra de menu. A transação ao ser
chamada, sempre deverá apontar uma tela normal.
11
 Subtela
A subtela faz parte de uma tela normal ou de outra subtela. A transação não
pode chamar uma subtela.
A subtela não pode possuir título ou barra de menu, pois os mesmos serão
herdados da tela normal, a qual a subtela está inserida.
A vantagem da utilização de subtelas é a reutilização das mesmas, ou seja, uma
subtela pode ser utilizada por várias subtelas.
As abas “Período 002.2010” e “Período 012.2009” utilizam a mesma subtela.
 Caixa de diálogo modal


A caixa de diálogo modal é uma tela vinculada à tela de chamada e o foco fica
preso a ela. Normalmente, é utilizada como tela de pop-up.
12
A tela seleção de visões é uma caixa de diálogo modal, e a tela normal que fica em segundo
plano permanece inativa enquanto a caixa de diálogo modal permanece ativa.
Configurações
 Manter os dados
Ao ativar esta opção, são suportadas para a tela no tempo de execução as

seguintes entradas de menu:
Sistema->Especificações do usuário->Manter dados
->Definir dados
->Eliminar dados
Deste modo, é possível manter no sistema as entradas efetuadas na tela. No

próximo processamento da tela (também em outro modo), o sistema insere
automaticamente nos campos de entrada as entradas mantidas.
Se a opção não for ativada, as entradas de menu não têm efeito no tempo de
execução da tela.
 Desativar a compressão da tela para o tempo de execução
Se o atributo "Desativar compactação de tempo de execução" não estiver

definido, no tempo de execução a tela é exibida em forma comprimida desde
que
 tenha pelo menos um campo (campo de texto, campo de
entrada/saída, elemento gráfico, subtela,quadro, ...) que é invisível ou
13
 tenha uma área de subtela cuja altura é maior do que a da subtela
utilizada.
O atributo não definido é o caso standard. Só em casos justificados se deve

desistir da compressão da tela no tempo de execução.
Se o atributo estiver definido, a tela não é exibida na forma comprimida

durante o tempo de execução.
A compressão é efetuada de acordo com a lógica seguinte:
 linhas onde existe pelo menos um campo invisível e nenhum visível são
"eliminadas", ou seja, as posições de linhas dos campos existentes
mais abaixo são reduzidas. Também os tamanhos de quadro são
reduzidos, caso necessário.
 quadros que estão em branco ou que só têm campos invisíveis são
eliminados.
 campos de entrada só são válidos como invisíveis se não estiverem
prontos para entrada (não ativos). Para isso são mantidos os campos
de palavra-chave.
 se a altura (número de linhas) de uma subtela for inferior à da área de
subtela em que deve processada, então as linhas restantes são válidas
como comprimíveis.
 durante a compressão, uma subtela é tratada como se os seus campos
estivessem diretamente na tela em cuja área de subtela deve ser
processada.
 O atributo de tela para a compressão ainda não tem qualquer
significado para a subtela.
 a compressão de um quadro é efetuada "orientada por objeto"; um
quadro e os campos aí contidos são examinados primeiro como tela
própria e comprimidos. Caso necessário, o quadro é reduzido e então é
feita uma tentativa de executar a "Eliminação" das linhas comprimidas
também para o ambiente do quadro.
 Campos que não estivéssem junto a um quadro antes da compressão,
também não estão junto de um quadro depois da compressão.
 Campos que estivéssem junto a um quadro antes da compressão,
também estão junto a este quadro depois da compressão, a não ser
que o quadro tenha sido comprimido fora destes campos.
 um step loop variável não pode ser aumentado através da
compressão.
 Tela-modelo - não executável


Este atributo é essencialmente determinado para a utilização interna SAP.
Com este atributo estão previstas telas que só servem como modelo ou padrão
e nunca devem ser executadas por eles próprios.
Se o atributo "tela modelo - não executável" estiver definido:
14
o a tela não pode ser gerada/ativada e, por isso, voltar a ser executada,
o o ramo "consistência de tela" não é executado para esta tela através da
verificação ampliada de programa (transações SLIN e TODO).
Se o atributo estiver definido, ainda são possíveis as verificações seguintes:
o verificação de síntaxe para a tela

o verificação de consistência para a tela
o verificação de layout para a tela
o Além disso é possível testar a tela também no atributo definido.
 Manter posição de rolagem
Este atributo foi pensado para telas longas, nas quais foi perdida a posição de
rolagem através de algumas ações.
Indica que a posição de rolagem da tela principal deve ser mantida, se a tela
for exibida várias vezes seguidas.
 S/barra ferrams.aplicação
Durante o tempo de execução de uma tela normalmente é exibida a barra de

botões. Se esse atributo estiver habilitado, a barra de botões não é
apresentada em tempo de execução, independentemente se estiver habilitada
ou não no status-gui da tela.
Outros atributos
 Tela seguinte
Neste campo, tem de ser indicado de forma estática o nº da próxima tela no

processo de transação. O nº da tela seguinte “0” provoca o encerramento da
transação ou o retorno de uma tela ou programa chamado para um nível
anterior à posição da chamada.
A tela seguinte também pode ser determinada de forma dinâmica em um

módulo com o comando 'SET SCREEN nnn'. Deste modo, o nº da tela seguinte
estático fica temporariamente sem efeito.
 Posição do cursor
Se o curso não deve ser posicionado no primeiro campo da tela pronto para
entrada, mas sim em outro campo, o nome desse campo tem de ser indicado.
Esta função também pode ser efetuada de forma dinâmica no pool de módulos
com o comando ABAP.
15
'SET CURSOR FIELD nome do campo'.
 Grupo de telas
É possível entrar uma seqüência de 4 caracteres no máximo, disponível

durante o tempo de execução da tela no campo SY-DYNGR.
Através do termo a entrar neste campo, podem ser atribuídas várias telas a um
mesmo grupo (de telas), que pode ser utilizado, por exemplo, para efetuar
uma modificação comum a todas as telas desse grupo.
Os grupos de telas são atualizados na tabela TFAWT, que contém, por grupo de
telas de um programa (pool de módulos), um texto dependente do idioma,
que descreve o grupo de telas.
Se for entrado na tela de atributos do Screen Painter um grupo de telas que

ainda não existe para o programa atual, o sistema cria uma entrada para
TFAWT.
Lista de Elementos
Todos os elementos inseridos na tela estão presentes na lista de elementos. A lista de

elementos apresenta as características dos elementos tais como textos, atributos especiais e
de exibição, agrupamentos e referências.
16
Os elementos são adicionados e modificados através do screen-painter e a lista de elementos
mantém as características definidas pelo usuário.
17
Screen Painter
Uma tela pode conter uma grande variedade de elementos, seja para apresentar o conteúdo
de um campo, seja para permitir a interação do usuário com o programa. O Screen Painter é
utilizado para organizar os elementos na tela.
Para acessar o Screen Painter é necessário que no ABAP Workbench (SE80), a tela desejada
esteja aberta e o botão Layout seja clicado.
18
Ao abrir o screen painter, o programador tem a disposição a palheta de elementos (1), a barra
de elementos(2) e a janela de atributos(3).
1 2
Palheta de Elementos
Os seguintes elementos podem ser utilizados na tela:
Campo texto
Insere um campo de saída de texto, o qual é utilizado como título de um objeto como um
campo de entrada e saída.
19
Campo de entrada/saída
É um campo utilizado para a entrada de dados pelo usuário. Além de um campo de entrada,
ele pode ser utilizado como um campo de saída de valores. Como exemplo, o campo pode ser
utilizado como título de campo um campo de entrada e dependendo do tipo de valor do
campo de entrada, o campo de saída receberá o valor apropriado.
Campo de Entrada
Campo de seleção
Campo utilizado para o usuário escolher uma ou mais opção. Quando o campo estiver
marcado, o valor transferido à variável atribuída ao campo de seleção é ‘X’. O tipo de variável
associado ao campo de seleção é CHAR.
Botão de Rádio
Utilizado para fornecer ao usuário opções. Ex.: Sim/Não, Aprovado/Reprovado.
O usuário só pode escolher uma opção e os campos devem ser agrupados para que somente
um valor seja selecionado.
O tipo de dado da variável atribuída ao campo é CHAR e o valor do campo marcado é 'X'.
20
Botão
O botão é um objeto para a execução de uma rotina. Para que o processador ABAP reconheça
que um botão foi pressionado, o botão tem uma propriedade chamada código de função.
O código de função é transferido para a variável de sistema SY-UCOMM para que o

programador possa criar uma rotina vinculada ao botão. O evento acionado pelo botão é o
evento PAI da tela onde o botão foi criado.
Controle de Fichas
O botão de controle de fichas permite a inserção de abas na tela para que os campos fiquem
organizados de acordo com a necessidade do usuário.
O único objeto que pode ser inserido nas abas é o objeto área de subtela. Podem ser
adicionadas várias abas no controle de fichas. Cada aba é um botão, o qual assume as mesmas
características do botão (código de função), com a adição do campo de referência, que é o
nome técnico da área subtela a ser adicionada no controle de ficha.
Cada botão tem sua área de subtela. No programa

module pool, é realizada a programação para
associar uma sub tela a área de subtela da Dynpro.
Por exemplo, ao clicar no botão “Compras”, a tela
0200 que está associada à área de sub tela de
compras será aberta na área abaixo do botão de
compras. E, ao clicar no botão “Vendas”, a tela
0300, que está associada à área de sub tela de
vendas, será aberta na área abaixo do botão de
vendas.
Controle de Fichas (Wizard)
O controle de fichas pode ser criado através de um assistente. De acordo com as opções
escolhidas pelo desenvolvedor, o sistema irá criar automaticamente as rotinas nos eventos PAI
e PBO.
21
Quadro
O quadro, ou moldura, é uma ferramenta para que o usuário possa organizar a tela agrupando
objetos tais como campos,
tabelas, controle de fichas e
botões.
O quadro permite que seja

adicionado um título, mas ao
fazer isso, é obrigatório a
definição do nome técnico do
quadro.
O quadro “Cadastro de clientes” possui o campo “Nome” e os botões de rádio “Estado Civil”.
Área de Subtela
A área de subtela são áreas que são associadas à telas do tipo subtela. No screen painter, é
nada mais do que uma área, onde através de programação no programa de module pool, a
mesma será associada á uma tela do tipo subtela. A associação pode ser estática ou dinâmica,
ou seja, mais de uma subtela pode ser associada à área de subtela.
A vantagem da utilização de área de subtela é a reutilização de subtelas em comum entre

várias telas.
Table Control
O objeto table control é uma tabela que permite que os dados sejam apresentados e
manipulados como uma tabela.
As características como quantidade de colunas, títulos de colunas, colunas fixas, linhas

horizontais e verticais e campos editáveis fica a critério do programador.
22
Table Control (Wizard)
O objeto Table Control pode ser criado através de um assistente e de acordo com as opções
selecionadas pelo desenvolvedor, o sistema cria automaticamente as rotinas de execução da
table control no programa de module pool.
Custom Control (Container)
O objeto Custom Control é utilizado para vincular caixas de texto, tabelas ALV GRID, ALV TREE
ou outros objetos através de ABAP OO.
23
Ícone Status
É um elemento de tela utilizado para representar o estado de um programa graficamente. O

nome técnico deve ser o mesmo do texto do tipo ICONS do dicionário ABAP.
Campo OK_CODE
Toda tela tem um campo de 20 caracteres chamado OK_CODE (também conhecido como
campo de código de função), o qual não é apresentado na tela. As ações do usuário que ativa o
evento PAI também insere o código de função correspon-dente nesse campo, de onde é
passado para o programa ABAP. Um nome deve ser associado ao campo OK_CODE para poder
ser utilizado por uma tela específica.
Todos os elementos de tela têm um conjunto de atributos, alguns os quais são definidos
automaticamente e outros que devem ser especificados no Screen Painter. Eles determinam
coisas como o leiaute dos elementos na tela. Os atributos dos elementos de tela podem ser
definidos no Screen Painter, seja para um simples elemento ou uma lista de elementos, o qual
lista todos os elementos pertencentes à tela atual. Alguns atributos que foram definidos
estaticamente no Screen Painter, podem ser sobregravados dinamicamente no programa
ABAP.
24
Campos de tela
Os campos de tela são campos da working memory de uma tela. Seu conteúdo é transferido
para os campos de nomes idênticos no programa ABAP no evento PAI e preenchido com os
valores de campos de nomes idênticos no evento PBO. Os campos de tela são associados com
os campos de entrada/saída na tela e com o campo OK_CODE. Os campos de entrada e saída
devem ter um nome único (Atributo de elemento Name). Isso fará com que o nome do campo
seja associado com o campo do programa ABAP (variável, por exemplo).
Os atributos técnicos tamanho e tipo de dados de um campo de tela são definidos pelos
atributos de elementos CompDef(1) e Formato(2).
1 2
Para o tipo de dados, uma das entradas do dicionário ABAP pode ser selecionada. Estas são
convertidas adequadamente quando os dados são transferidos entre a tela e o programa
ABAP. Ao definir a opção “Do Dict".”, o nome, tamanho e o tipo de dados são definidos
automaticamente. Caso contrário, esses atributos deverão ser definidos manualmente no
Screen Painter. O mais importante é a definição do campo OK_CODE para cada tela, de modo
que o campo de uma tela correspondente possa ser definida. Isso permite a utilização do
campo OK_CODE no programa ABAP.
Os elementos de exposição, tais como campos de texto ou quadros não estão ligados a
campos da tela, e não precisa de um nome de campo exclusivo.
Assim como os campos de tela definidos no Screen Painter, as telas também reconhecem os
mesmos campos das variáveis de ambiente do programa ABAP. Entretanto, em telas, os
campos de sistema são administrados na estrutura SYST e não na SY. Portanto, ele deve ser
utilizado na forma SYST-<nome>.
25
Exemplo de tela
Um pequeno trecho de código tenha os seguintes comandos:
DATA: text(10),
number TYPE i.
CALL SCREEN 100.
A tela 100, criada no Screen Painter, contém dois campos SPFLI-CARRID e SPFLI-CONNID do
dicionário ABAP, e dois campo TEXT e NUMBER, do programa ABAP. Ele também contém três
campos de textos e um quadro. A tela apresenta a seguinte forma:
As colunas da lista de elementos que são relevantes para os campos de tela são as seguintes:
A tela possui quatro campos de entrada/saída. Cada um desses campos está associado a um
campo no programa ABAP. Os tipos de dados e tamanho dos campos da tela são copiados do
dicionário ABAP ou do programa. No exemplo acima, o campo OK necessita de um nome – por
exemplo, OK_CODE – para associá-lo a uma variável do programa ABAP.
26
Lógica de Processamento
A lógica de processamento de uma tela contém a parte procedural de uma tela. Ele é criado no
editor de lógica de processamento, o qual é similar ao editor ABAP. A linguagem utilizada para
programar a lógica de processamento da tela tem a sintaxe similar do ABAP, mas não faz parte
do ABAP. Às vezes é definido como linguagem de tela.
Diferentemente dos programas ABAP, a lógica de processamento não contém declaração

explícita de dados. Os campos de tela são definidos inserindo os elementos na tela.
A lógica de processamento é como um programa ABAP o qual é utilizado como um container

para processamento em blocos. Há quatro eventos de bloco, em que cada um é inserido com o
comando de tela PROCESS:
PROCESS BEFORE OUTPUT.

...
PROCESS AFTER INPUT.

...
PROCESS ON HELP-REQUEST.
...
PROCESS ON VALUE-REQUEST.
...
27
Como no ABAP, o evento de bloco é iniciado pelo comando correspondente e é concluído
quando o próximo bloco é iniciado ou quando o programa é finalizado. Os dois primeiro
comandos são criados automaticamente pelo Screen Painter, quando a tela é criada. Os
eventos correspondentes são ativados pelo ambiente de execução:
 PROCESS BEFORE OUTPUT (PBO) é automaticamente ativado depois do

processamento do PAI da tela anterior e depois que a tela atual é apresentada. O
processamento do PBO da tela pode ser programado nesse bloco. Ao final do
processamento do PBO, a tela é apresentada ao usuário.
 PROCESS AFTER INPUT (PAI) é ativado quando o usuário seleciona uma função na
tela (clique em um botão, teclar ENTER). O processamento do PAI da tela pode ser
programado nesse bloco. Ao final do processamento do PAI, o sistema chama a
próxima tela ou a partir do ponto em que a tela foi chamada.
 PROCESS ON HELP-REQUEST(POH) e PROCESS ON VALUE_REQUEST(POV) são

ativados quando o usuário solicita a ajuda (F1) ou a ajuda de pesquisa (F4),
respectivamente. O código pode ser programado nos eventos de bloco
correspondente. Ao final do processamento, o sistema executa o processamento
da tela atual.
Como nos eventos, os eventos de bloco só podem ser programados para o evento no qual a
lógica de processamento irá reagir. Entretanto, a lógica de processamento da tela deve conter
no mínimo os dois comandos PROCESS BEFORE OUTPUT e PROCESS AFTER INPUT, na ordem.
Dentro dos eventos de bloco, os seguintes comandos podem ser utilizados:
28
CALL Chama uma subtela
CHAIN Inicia o processamento chain.
ENDCHAIN Finaliza o processamento chain.
ENDLOOP Finaliza o processamento em LOOP
Referência a um campo. É possível

FIELD
combinar com os comandos MODULE e SELECT
LOOP Inicia o processamento em LOOP

MODIFY Modifica uma tabela
MODULE Identifica um módulo de processamento
ON Utilizado com o comando FIELD
PROCESS Define um evento de processamento
SELECT Verifica uma entrada em uma tabela
VALUES Define os valores de entrada permitido
Processamento de telas
Existem dois métodos de chamar uma tela. É utilizar uma transação ou o comando CALL
SCREEN no programa ABAP. Ao chamar a tela, o evento PROCESS BEFORE OUTPUT (PBO) é
chamado, e o evento de bloco correspondente é processado. A tela é apresentada ao usuário
até que o mesmo ative o evento PROCESS AFTER INPUT (PAI) ao escolher uma função. Nesse
meio tempo, pode haver o processamento de ajuda de pesquisa(F4) ou ajuda(F1). O evento de
bloco correspondente é processado, se existir. O propósito principal dos evento de bloco na
lógica de processamento da tela é chamar o módulos no programa ABAP e fornecer dados ao
programa ABAP.
Ações do usuário na tela
Existem várias maneiras de o usuário interagir com as telas.
Preenchimento de campos de entrada
O usuário pode inserir valores em qualquer campo de entrada disponível na tela, ou alterar o
valor com o mouse no caso de botão de rádio e campo de seleção. Inserir valor nos campos
normalmente não dispara o evento PAI. Exceções a isso são botões de rádio e campos de
seleção com código de função e campos de entrada com caixa de listagem.
29
Disparando o evento PAI
Há uma série de ações que concluem a interação do usuário com a tela no SAPgui e transfere o
controle de volta para o ambiente de execução no servidor de aplicação, onde o evento PAI é
disparado.
As ações são:
 Selecionando um botão na tela

 Selecionado um campo de seleção ou botão de rádio com código de função atribuído
 Selecionando uma função na barra de menu, barra de botões ou a barra de aplicação
 Utilizando uma tecla de atalho no teclado
 Selecionando qualquer entrada num caixa de listagem
Todas essas ações tem em comum que elas estão associadas com código de função (function
code).
 O código de função de um botão, campo de seleção, botão de rádio ou caixa de

listagem numa tela é definido nos atributos de elementos correspondentes
 O código de função na barra de menu, barra de botões ou a barra de aplicação são
definidos no STATUS GUI
 O código de função das teclas de atalho também são definidos no STATUS GUI
Se o campo OK_CODE na lista de elementos possui um nome (e conseqüentemente está

atribuído a uma variável), ele é preenchido automaticamente quando o usuário toma uma
ação. Se existir uma variável com o mesmo nome do campo OK_CODE, é possível saber a ação
tomada pelo usuário no módulo PAI no programa ABAP. Se o campo OK_CODE não tem um
nome, o evento PAI é disparado, mas não há uma variável para receber o valor do código de
função.
O evento PAI é sempre disparado quando o usuário redimensiona a tela contendo os

elementos com o atributo Redimensionamento definidos como ativo. Isto é aplicável a table
controls, área de subtelas e custom controls (containers).
Processamento de campos de entrada/saída
Campos de entrada/saída podem ser campos convencionais no qual o usuário pode inserir os
valores utilizando o teclado ou selecionado através de uma caixa de listagem, ou caixa de
seleção ou botão de rádio, onde o mouse é requerido. Todos os campos de entrada/saída têm
um nome associando-os aos campos da tela. O tipo de dados dos campos da tela determina o
formato de entrada. Por exemplo, não é possível inserir uma letra num campo numérico. A
tela reconhece quando o usuário tenta inserir valores inválidos. Campos de seleção e botões
de rádio tem o tipo de dados CHAR e tamanho 1. A opção selecionada terá o valor ‘X’ e quando
desmarcado o valor será SPACE.
30
O programa ABAP deve conter objetos de dados com o mesmo nome correspondente ao
campo da tela, senão o dado poderá perder-se. Os campos ABAP para campos de seleção e
botão de rádio devem ser do tipo C e tamanho 1.
Depois que o evento PBO foi processado, os campos das telas são preenchidos com os valores
dos campos ABAP. Antes ou durante o evento PAI, os valores dos campos da tela são escritos
nos campos ABAP. O botão de rádio só pode ter um valor selecionado dentro de um grupo de
botões de rádio. Se mais de um campo de botão de rádio possuir o valor ‘X’, o programa é
finalizado com erro.
31
Campos de programas locais
Para a utilização de campos de entrada/saída no programa local, o campo deve ser criado no
programa ABAP, o programa ser ativado e então copiar os campos do programa para a tela.
Deve-se evitar alterar o nome ou a característica dos campos no programa ABAP, para que não
perca a associação com os campos da tela.
Criação dos campos no programa ABAP.
Criação dos campos no Screen Painter e na lista de elementos
Apresentação da tela para o usuário
32
Campos de tela com referência ao Dicionário
Se os campos de entrada/saída são necessários em mais de um programa e houver a

necessidade de utilizar a informação do dicionário ABAP, tais como nome de campo, campo de
ajuda (F1) e ajuda de pesquisa (F4), então os campos devem ser copiados do dicionário ABAP.
Os nomes dos campos devem ser nomeados de forma idêntica à work área no programa ABAP
utilizando o comando TABLES. A declaração do campo de tela a uma work área de mesmo
nome, mas declarado com o comando TYPES é insuficiente para os dados serem transferidos
entre a tela e o programa ABAP.
Para evitar os conflitos de nomes entre campos de tela, work áreas nos programas e tabelas
transparentes, é aconselhável criar uma estrutura no dicionário ABAP para as telas, contendo
os campos de entrada/saída que forem utilizadas para uma ou mais telas do programa. As
work áreas que são declaradas com o comando TABLES no programa ABAP funcionam
exclusivamente como uma interface entre o programa e a tela.
A vantagem de referenciar ao tipo de dados do dicionário ABAP é que os campos da tela e do

programa ABAP são atualizados automaticamente se houver alteração do tipo de dados.
Exemplo:
Criação do programa ZFLIGHT, onde ao inserir o código da companhia aérea e o número do

vôo, o sistema obtém os dados do vôo e apresenta ao usuário.
33
Na criação da tela, a tela seguinte definida
na tela 0100 é ela mesma.
Os componentes da estrutura SDYN_CONN

do dicionário ABAP é utilizado como campo
da tela.
A estrutura SDYN_CONN existe no dicionário

ABAP especialmente para telas que utilizam o
modelo de dados de vôo. Ele contém os
componente da tabela transparente SPFLI e
também um componente chamado MARK. O
componente MARK utiliza o domínio S_FLAG, o
qual só aceita os valores ‘X’ e SPACE. Na tela final,
apresentada ao usuário, o texto do campo MARK
foi substituído pelo texto “Cancelar”. Para todos
os outros campos, os textos do dicionário ABAP
foram mantidos.
34
O atributo de edição de alguns campos foi desmarcado no Screen Painter.
O usuário pode entrar com os valores para o campo “Companhia Aérea” e “Número do Vôo”.
O valor dos campos é verificado
automaticamente na tabela transparente
de acordo com a definição no dicionário
ABAP. As opções de ajuda (F1) e ajuda de
pesquisa (F4) também são herdadas do
dicionário ABAP.
As verificações nos campos são realizadas automaticamente antes que qualquer módulo seja
chamado no programa ABAP. Os usuários não podem inserir valores inexistentes no campo
“Companhia aérea”, caso ela não exista na tabela transparente SCARR. Da mesma forma o
campo “Número do vôo” não irá aceitar os valores que não estejam presentes na tabela
transparente SPFLI e o campo “Cancelar” só irá aceitar os valores X ou SPACE, devido aos
valores pré-definidos no domínio S_FLAG. Não há a necessidade de realizar a programação
dessas verificações no programa ABAP.
A lógica de processamento da tela 0100 fica da seguinte forma:
O módulo USER_COMMAND_0100 no
evento PAI no programa lê os dados do
banco de dados com os campos chaves
especificados (e verificados) na tela e
envia-os de volta para a tela no módulo
INIT_SCREEN_100 do evento PBO.
A work-area SYDN_CONN, definido com o
uso do comando TABLES, atua como uma
interface entre o programa e a tela. Enquanto isso, o dado proveniente do banco de dados é
processado na work-area WA_SPFLI. Se o usuário inserir o valor ‘X’ no campo “Cancelar” e
teclar “Enter”, o programa é finalizado.
35
O código no programa ABAP fica da seguinte forma:
36
Botões na tela
Botões são os únicos elementos da tela que disparam o evento PAI quando o usuário os
selecionam. Nos atributos do botão é definido o código de função com até 20 posições.
Botões tem um texto – um texto que é definido de forma estática nos atributos – e também
pode possuir ícones. Se o atributo “Campo de saída” estiver marcado, o texto do botão pode
ser definido dinamicamente no programa ABAP. Para isso, é necessária a criação de um campo
no programa ABAP com o mesmo nome do botão e então atribuir o texto desejado para o
campo ABAP, antes da apresentação da tela. Os ícones também podem ser atribuídos
dinamicamente no texto do botão. A biblioteca de ícones está contida no programa include
<ICON>. Por exemplo, o ícone ICON_CANCEL ( ) tem o código @0W@.
Em cada evento PAI, o código de função, desde que não esteja vazio, é transferido ao campo
de sistema SYST-UCOMM (SY-UCOMM) e atribuído ao campo OK_CODE da tela. O código de
função é vazio se o atributo “código de função” não foi preenchido no Screen Painter. Antes de
utilizar o campo OK_CODE, é necessário atribuir um campo do programa ABAP a ele, no Screen
Painter.
Um dos meios de permitir os usuários a escolher a funções que disparam o evento PAI e enviar
os códigos de função para o programa é através do Status-GUI. A principal razão é o espaço – o
Status GUI pode conter mais funções do que poderia ser alocado na tela com os botões.
Exemplo:
Ao selecionar um dos quatro botões, o texto correspondente ao botão selecionado deverá ser
apresentado no campo de saída. Ao selecionar o botão “Cancelar” o programa será finalizado.
No programa ABAP, os
campos OK_CODE e
OUTPUT possuem os
mesmos nomes dos
campos da tela 100.
37
No Screen Painter são criados os botões e o campo de saída com o seguinte leiaute:
Screen Painter Lista de elementos
O campo de saída OUTPUT teve o atributo “Campo saída” definido como ativo no Screen
Painter.
Na lógica de processamento da tela, foi inserida a chamada de um módulo.
Quando o usuário seleciona um botão, o evento PAI é disparado. O código de função do botão
é atribuído ao campo da tela OK_CODE, o qual é então atribuído ao campo do ABAP OK_CODE.
O módulo USER_COMMAND_0100 é então processado.
Código fonte do programa ABAP
38
Primeiramente, o conteúdo do campo OK_CODE é copiado para a variável auxiliar SAVE_OK e
o OK_CODE é inicializado. Isto sempre deve ser feito, pois isso garante que o campo da tela
OK_CODE sempre será reinicializado antes do evento PBO e pode, portanto, sem querer conter
um valor incorreto.
Próximo, na estrutura CASE, um símbolo de texto é atribuído ao campo OUTPUT de acordo

com o botão que o usuário selecionou. O texto é apresentado no campo de saída na tela. Se o
usuário selecionar o botão Cancelar, o programa é finalizado.
39
Campo de seleção e botões de radio com código de função
No Screen Painter, é possível adicionar um código de função (até 20 posições) em campos de

seleção e botões de rádio.
Campos de seleção e botões de rádio sem um código de função agem como campos de
entrada/saída normais. Ao clicar nos objetos, o conteúdo dos campos são alterados, mas não
dispara o evento PAI.
Quando o código de função é atribuído em um campo de seleção ou botão de rádio, ao clicá-

los não só altera o conteúdo mas também dispara o evento PAI e coloca o cursor no campo
OK_CODE.
Enquanto é possível atribuir um código de função para cada campo de seleção, só é possível
atribuir um código de função para todos os botões de rádio em um grupo. Ao atribuir um
código de função para um botão de rádio de um grupo, todos os botões do grupo recebem
automaticamente o código de função.
Os campos de seleção e botões de radio podem ser utilizados da seguinte forma:

 Para o processamento de partes da tela. Por exemplo, somente quando um botão de
rádio ou um campo de seleção for selecionado, os dados são lidos e atribuídos nos
campos de entrada/saída correspondentes
 Os campos podem ser preenchidos com padrões dependendo dos valores dos campos
de seleção ou botão de rádio. Um exemplo típico poderia ser a configuração de
formatação de caracteres. Os campos de entrada podem ser processados
separadamente, mas é possível preencher todos os campos de entrada
simultaneamente e consistentemente pela escolha de um padrão.
 Possibilidade de controlar dinamicamente as modificações na tela diretamente
utilizando campos de seleção ou botões de rádio. Por exemplo, os campos de
entrada/saída não podem aceitar dados até que o usuário selecione um botão de
rádio.
Exemplo:
Ao selecionar um dos botões de rádio, o valor “MARCADO” será apresentado no campo de

entrada/saída correspondente. Ao clicar no botão Cancelar, o processamento será finalizado.
Segue abaixo o leiaute do programa.
40
No Screen Painter são criados os botões e o campo de saída com o seguinte leiaute:
Screen Painter Lista de elementos
Na lógica de processamento da tela, foi inserida a chamada de um módulo.
Cada vez que um dos botões de rádio é selecionado, o evento PAI é disparado e o código de
função RADIO e o conteúdo dos campos da telas são transferidos para o programa ABAP. O
módulo USER_COMMAND_0100 preenche os campos FIELD1 até FIELD3 de acordo com o
botão de rádio selecionado. O conteúdos dos campos aparecem na próxima vez que a tela é
enviada.
O evento PAI também é disparado se o campo de seleção foi selecionado. Neste caso, o código
de função CANCEL é transferido para o programa ABAP e o módulo USER_COMMAND_0100
termina o programa imediatamente.
41
Status GUI
O Status GUI é um componente independente do programa ABAP. A criação dele é realizado

no ABAP Workbench (SE80) utilizando o Menu Painter.
A função de um Status GUI é fornecer ao usuário uma gama de funções na tela. Cada função
está associada a um código de função, e quando o usuário escolhe uma função, o evento PAI é
disparado. Em cada evento PAI, o código de função, desde que não esteja vazio, é transferido
no campo de sistema SYST-UCOMM (SY-UCOMM) e atribuído ao campo da tela OK_CODE.
Todos os códigos de função em um programa ABAP, além daqueles apenas atribuído a botões
nas telas, são definidos e administrados no Menu Painter.
Transação SE80, botão direito no nome

do programa, Criar-> Status GUI
Quando você definir um código de função no Menu Painter, você atribui isso a uma entrada de
menu em uma barra de menu e, possivelmente, também a uma tecla de função livremente
atribuídos no teclado. Códigos de função que são atribuídas a uma tecla de função também
podem ser atribuídos a um ícone na barra de ferramentas padrão ou um botão na barra de
ferramentas. A Status GUI consiste de uma barra de menu, uma barra de botões, uma barra de
ferramentas e configuração de teclas de função.
42
Barra de aplicação Barra de menu
Barra de ferramentas
padrão
No Menu Painter, as funções que são atribuídas aos ícones na barra de ferramentas padrão
também devem ser atribuídas a códigos de funções particulares. Eles não podem ser
atribuídos livremente. Ao invés disso, o sistema automaticamente os atribui para o código de
função correspondente quando o desenvolvedor atribui o código de função a um ícone. Pelo
menos umas das funções Voltar (F3), Sair (Shift+F3) e Cancelar (F12) devem ser
ativados, pois deste modo o usuário pode sair da tela. A atribuição das teclas de função aos
botões da barra de ferramentas não é fixada.
Teclas de função e código de função especiais
Algumas teclas de função e código de função têm funções especiais.
Teclas de funções reservadas

As teclas de funções abaixo não disparam o evento PAI, mas são reservados para outras
funções:
 F1 chama a ajuda do campo
 F4 chama a ajuda de pesquisa
 F10 posiciona o cursor na barra de menu
43
Teclas de função para a barra de ferramentas padrão
As seguintes teclas de função estão fortemente associadas aos ícones da barra de ferramentas
padrão.
Tecla de Ícon
Função e Propósito
Ctrl+S Salvar
F3 Voltar
Shift+F3 Sair
Esc ou F12 Cancelar
Ctrl+P Imprimir
Ctrl+F Pesquisar
Ctrl+G Pesquisar Próximo
Ctrl+PageUp Primeira Página
PageUp Pagina Anterior
PageDn Próxima Página
Ctrl+PageDn Última Página
A tecla ENTER
A tecla ENTER pertence ao ícone na barra de ferramentas padrão, e está sempre ativo,
mesmo que nenhuma função esteja atribuída a ele no Status GUI. O evento PAI é sempre
disparado quando o usuário tecla ENTER. Os seguintes códigos de função podem transferidos
para o SY-UCOMM ou o campo OK_CODE.
 Qualquer entrada no campo de comando quando o usuário tecla ENTER
 Se não houver nenhuma entrada no campo de comando, qualquer código de função
atribuído à tecla ENTER no Menu Painter
 Se o campo de comando não contém uma entrada e não há código de função atribuída
a tecla ENTER no Menu Painter, o código de função permanece vazio e portanto não é
transferido para o SY-UCOMM ou o campo OK_CODE
Definindo o Status GUI
Para associar o Status GUI para uma tela, é necessário utilizar o seguinte comando ABAP:
SET PF-STATUS <stat> [OF PROGRAM <prog>] [EXCLUDING <f>|<itab>].
Este comando define a interface do usuário para todas as telas subseqüentes de uma
seqüência de telas até que a próxima seja definida com o uso de um novo comando SET PF-
STATUS. O Status GUI <stat> deve ser um componente do programa ABAP corrente, a menos
44
que seja utilizada a adição OF PROGRAM no comando SET PF-STATUS para utilizar o Status GUI
de outro programa <prog>.
No evento PBO (Process Before

Output) é criado uma chamada
para o módulo STATUS_0100, o
qual irá conter o código de
chamada do Status GUI.
A chamada do Status GUI deve

ser sempre no evento PBO.
Dentro do módulo
STATUS_0100, há o comando
para a chamada o Status GUI. No
exemplo ao lado, o comando SET
PF-STATUS irá carregar o Status
GUI chamado “STATUS_MAIN”,
que faz parte do programa
ABAP.
45
A adição EXCLUDING permite a alteração da aparência e função de um status GUI
dinamicamente. É possível definir um Status GUI global e então desabilitar as funções que não
são necessárias utilizando a adição EXCLUDING. Especifique <f> para desabilitar o código de
função armazenado no campo <f>. Especifique <itab> e as linhas da tabela interna <itab> para
desabilitar os códigos de função armazenados na tabela interna <itab>. O campo <f> e as
linhas da tabela interna <itab> devem ser do tipo C e ter o tamanho de 20 posições.
A função “Exportar” definida no Status GUI “STATUS_MAIN”

poderá ser desabilitado com a adição EXCLUDING no
comando SET PF-STATUS, conforme a figura abaixo:
Função “&EXPORTAR”
A função “Exportar” possui o código de função

“&EXPORTAR” e ao adicionar na variável V_FUNC a
mesma será utilizada no comando SET PF-STATUS
para desabilitar a função.
46
Chamar módulos de diálogo ABAP
A tarefa principal da lógica de processamento da tela é chamar os módulos ABAP em um

programa ABAP. Isto é feito através do comando MODULE, o qual pode ser programado nos
quatro eventos de bloco da área da lógica de processamento da tela. No evento PBO, este
comando pode ser utilizado para chamar qualquer módulo no programa ABAP, o qual foi
definido utilizando
MODULE <mod> OUTPUT.

...
ENDMODULE.
Nos eventos PAI, POV e POH, o comando pode ser utilizado para chamar qualquer módulo no
programa ABAP, o qual foi definido utilizando
MODULE <mod> INPUT.

...
ENDMODULE.
É tecnicamente possível ter dois módulos com o mesmo nome no mesmo programa, sendo um
definido com o INPUT e o outro com o OUTPUT, entretanto isso não é recomendado.
Chamadas de módulos simples
Para chamar um módulo, é necessário utilizar o seguinte comando:
MODULE <mod>
O sistema inicial o módulo <mod>, o qual deve ter sido definido no mesmo evento de bloco no
qual a chamada ocorre.
Se na área de lógica de processamento o módulo é chamado, o transporte de dados entre o
programa ABAP e a tela é a seguinte:
 No evento PAI, todos os dados da tela são transportados para o programa ABAP
(desde que haja campos de programa com o mesmo nome dos campos da tela) depois
da checagem automática de entrada e antes do primeiro módulo PAI é chamado. Isto
inclui o conteúdo dos campos de sistema (por exemplo, SY-UCOMM, o qual contém o
código de função corrente).
 No final do último módulo PBO, e antes da tela ser apresentada, todos os dados são
transportados do programa ABAP para os campos de mesmo nome na tela.
47
Os dados são transportados entre a tela e o programa ABAP no início e final de cada dialog
step no servidor de aplicação. Não confunda isto com o transporte de dados entre uma tela no
servidor de aplicação e o SAPgui na estação de trabalho.
Exemplo:
PROGRAM demo_dynpro_module.
TABLES demo_conn.
DATA: ok_code TYPE sy-ucomm,
save_ok LIKE ok_code,
wa_spfli TYPE spfli.
CALL SCREEN 100.
MODULE init_screen_100 OUTPUT.
MOVE-CORRESPONDING wa_spfli TO demo_conn.
ENDMODULE.
MODULE status_0100 OUTPUT.
SET PF-STATUS 'STATUS_100'.
SET TITLEBAR '100'.
ENDMODULE.
MODULE clear_ok_code INPUT.
save_ok = ok_code.
CLEAR ok_code.
ENDMODULE.
MODULE get_data INPUT.
MOVE-CORRESPONDING demo_conn TO wa_spfli.
CLEAR demo_conn.
ENDMODULE.
MODULE user_command_0100 INPUT.
CASE sy-dynnr.
WHEN 0100.
CASE save_ok.
WHEN 'CANCEL'.
48
LEAVE PROGRAM.
WHEN 'DISPLAY'.
PERFORM read_data.
WHEN 'CLEAR'.
CLEAR wa_spfli.
ENDCASE.
...
ENDCASE.
ENDMODULE.
FORM read_data.
SELECT SINGLE
cityfrom airpfrom cityto airpto fltime deptime arrtime
INTO CORRESPONDING FIELDS OF wa_spfli
FROM spfli
WHERE carrid = wa_spfli-carrid AND connid = wa_spfli-connid.
ENDFORM.
Segue abaixo a lógica de processamento:
MODULE INIT_SCREEN_100.
MODULE STATUS_0100.
MODULE CLEAR_OK_CODE.
MODULE GET_DATA.
MODULE USER_COMMAND_0100.
No status GUI “STATUS_100”, o símbolo (F12) é ativado com o código de função CANCEL, e
as funções e são atribuídos às teclas de função F5 e Shift+F12, respectivamente.
49
Ajuda de pesquisa
A ajuda de pesquisa(F4) é uma função padrão do sistema e conseqüentemente não pode ser
atribuído outros códigos de função para a tecla de atalho F4.
 Se o usuário teclar F4 ou o botão de ajuda de pesquisa ( ) à direita do campo de
entrada, uma lista de possíveis entradas são apresentadas para o campo em questão.
O usuário pode escolher um ou mais valores, o qual é copiado para o campo da tela.
Há dois modos de fazer com que a ajuda de pesquisa esteja disponível para o usuário. É
possível utilizar a ajuda de pesquisa contida no dicionário de dados ou programá-la módulo de
diálogo.
Ajuda de pesquisa no módulo de diálogo
Os módulos de diálogos podem ser chamados no evento PBO utilizando o comando de evento
PROCESS ON VALUE_REQUEST.
PROCESS ON VALUE-REQUEST.
FIELD <f> MODULE <mod>.
Após o comando PROCESS ON VALUE_REQUEST, somente o comando MODULE pode ser

utilizado em conjunto com o comando FIELD. Quando o usuário tecla F4 para o campo <f>, o
sistema chama o módulo <mod> pertencente ao campo <f>. Se houver mais de um comando
FIELD para o campo <f>, somente o primeiro será executado. O módulo <mod> é definido no
programa ABAP como um módulo PAI normal.
Existem alguns módulos de funções que podem ser utilizados para auxiliar na programação da
ajuda de pesquisa no evento POV. Eles fornecem suporte a ajuda de pesquisa e são
responsáveis pelo transporte dos dados entre a tela e a ajuda de pesquisa. Eles possuem o
prefixo F4IF_. Os mais importantes são:
 F4IF_FIELD_VALUE_REQUEST
Chama a ajuda de pesquisa do dicionário ABAP de forma dinâmica. Os nomes de
componentes de uma estrutura ou de uma tabela de banco de dados podem ser
transferidos do dicionário de dados para o módulo de função pelos parâmetros de
importação TABNAME e FIELDNAME. O módulo de função inicia a ajuda de pesquisa
do dicionário ABAP para este componente. Todos os campos relevantes da tela são
lidos. Se os parâmetros de importação DYNPPROG, DYNPNR e DYNPROFIELD, os
valores selecionados pelo usuário são retornados aos campos correspondentes na tela.
Se o parâmetro de tabela for especificado, o resultado é transferido para a tabela ao
invés da tela.
 F4IF_INT_TABLE_VALUE_REQUEST
50
Esta função apresenta uma lista que foi criada no programa ABAP. A lista de valores é
transferida para o módulo de função no parâmetro de tabela VALUE_TAB. Se os
parâmetros de importação DYNPPROG, DYNPNR e DYNPROFIELD, os valores
selecionados pelo usuário são retornados aos campos correspondentes na tela. Se o
parâmetro de tabela for especificado, o resultado é transferido para a tabela ao invés
da tela.
Há também dois módulos de função – DYNP_VALUES_READ e DYNP_VALUES_UPDATE – os

quais podem ler os valores dos campos da tela e retornar os valores a eles durante o
processamento do evento POV. Para mais informações, consulte a documentação do módulo
de função.
Caixa de Listagem
Bem como a ajuda de pesquisa, no qual os valores aparecem em uma tela à parte, os campos
de entrada/saída podem ser definidas como caixa de listagem. A caixa de listagem fornece ao
usuário um conjunto de valores pré-definidos. Não é possível entrar com um valor numa caixa
de listagem, ao invés disso, o usuário deve selecionar um valor da listagem. Quando o usuário
escolhe um valor, o evento PAI pode ser disparado simultaneamente. Se a caixa de listagem é
utiliza em um campo, a ajuda de pesquisa não pode ser utilizada ao mesmo tempo.
Uma caixas de listagem é uma lista de valores contendo uma única coluna de texto de até 80
caracteres. Internamente, cada campo tem uma chave de até 40 caracteres. Quando o usuário
seleciona uma linha, o conteúdo do campo texto é inserido no campo de entrada da tela, e o
conteúdo da chave é inserido no campo da tela. Os conteúdos e tamanho dos campos de
entrada/saída e o campo da tela não são necessariamente os mesmos.
Para transformar um campo de entrada/saída em um campo de caixa de listagem, o valor L ou

Listbox deve ser atribuído no atributo do campo no Screen Painter.
51
O código de função pode ser atribuído na caixa de listagem. Nesse caso, o
evento PAI é disparado imediatamente quando o usuário seleciona um
valor da listagem, e o código de função é inserido nos campos SY-UCOMM
e OK_CODE.
Se a caixa de listagem foi atribuída em um campo de entrada/saída, o

atributo “Lista de Valores” pode ser utilizado para determinar como o valor
da listagem deve ser compilado. Há duas possibilidades:
 Lista de valores da ajuda de pesquisa

Se nenhum valor for atribuído no atributo “Lista de Valores”, o
campo texto utiliza a primeira coluna apresentada da ajuda de
pesquisa atribuída ao campo da tela. A ajuda de pesquisa pode ser
definida no dicionário ABAP, na tela ou no evento POV.
 Lista de valores do programa ABAP

Se a opção “A” do atributo lista de valores foi selecionada, os
valores devem ser preenchidos antes da tela ser apresentada ao
usuário (evento PBO), utilizando o módulo de função
VRM_SET_VALUES. Ao utilizar esse módulo de função, uma tabela
interna do tipo VRM_VALUES deve ser atribuída ao parâmetro de
importação VALUES do módulo de função. VRM_VALUES pertence
ao grupo de tipos VRM. O tipo de linha é uma estrutura que
consiste de dois campos textos KEY (40 posições) e TEXT (40
posições). Na tabela interna, possíveis entradas de usuário podem
ser combinadas do campo KEY com qualquer texto no campo TEXT.
No parâmetro de importação ID, é especificado o campo de
entrada/saída definida como caixa de listagem.
52
Exemplo:
REPORT demo_dynpro_dropdown_listbox.
TYPE-POOLS vrm.
DATA: name TYPE vrm_id,
list TYPE vrm_values,
value LIKE LINE OF list.
DATA: wa_spfli TYPE spfli,
ok_code TYPE sy-ucomm,
save_ok TYPE sy-ucomm.
TABLES demof4help.
name = 'DEMOF4HELP-CONNID'.
CALL SCREEN 100.
MODULE cancel INPUT.
LEAVE PROGRAM.
ENDMODULE.
MODULE init_listbox OUTPUT.
CLEAR demof4help-connid.
SELECT connid cityfrom cityto deptime
FROM spfli
INTO CORRESPONDING FIELDS OF wa_spfli
WHERE carrid = demof4help-carrier2.
value-key = wa_spfli-connid.
WRITE wa_spfli-deptime TO value-text USING EDIT MASK '__:__:__'.
CONCATENATE value-text
wa_spfli-cityfrom
wa_spfli-cityto
INTO value-text SEPARATED BY space.
APPEND value TO list.
ENDSELECT.
CALL FUNCTION 'VRM_SET_VALUES'
EXPORTING
id = name
values = list.
ENDMODULE.
MODULE user_command_100.
53
save_ok = ok_code.
CLEAR ok_code.
IF save_ok = 'CARRIER' AND NOT demof4help-carrier2 IS INITIAL.
LEAVE TO SCREEN 200.
ELSE.
SET SCREEN 100.
ENDIF.
ENDMODULE.
MODULE user_command_200.
save_ok = ok_code.
CLEAR ok_code.
IF save_ok = 'SELECTED'.
MESSAGE i888(sabapdocu) WITH text-001 demof4help-carrier2
demof4help-connid.
ENDIF.
ENDMODULE.
A tela seguinte definida na tela 100 é a 200 (definida estaticamente) e

tem a forma abaixo:
54
O componente CARRIER2 da estrutura DEMOF4HELP do dicionário
ABAP é atribuído ao campo de entrada. O atributo da caixa de
listagem é definido como “L”, e tem o tamanho de saída de 15
posições.
O atributo “Lista de Valores” está

vazio e possui o código de função CARRIER.
O botão possui o código de

função CANCEL com o
atributo categoria de
função ”E”.
55
A lógica de processamento da tela 100 tem o seguinte código:
MODULE CANCEL AT EXIT-COMMAND.
A tela seguinte definida para a tela 200 é a tela 100 (definida estaticamente) e tem a forma
abaixo:
O componente CONNID da estrutura DEMOF4HELP do

dicionário ABAP é atribuído ao campo de entrada. O atributo da
caixa de listagem é definido como “L”, e tem o tamanho de
saída de 30 posições.
O atributo “Lista de Valores” está definido com o valor “A” e possui o

código de função SELECTED.
O botão possui o código de função

CANCEL com o atributo categoria de
função ”E”.
56
A lógica de processamento da tela 200 tem o seguinte código:
MODULE INIT_LISTBOX.
O usuário não pode entrar nenhum valor nos campos da tela. Quando o campo é selecionado
na tela 100, uma lista de valores aparece na caixa de listagem, compilado de ajuda de pesquisa
atribuído ao campo DEMO4HELP_CARRIER2. A ajuda de pesquisa é H_SCARR, a qual está
atribuída à tabela de verificação SCARR. A listagem contém os nomes das companhias aéreas.
Quando o usuário seleciona uma entrada, o campo de entrada é preenchido com o código da
companhia aérea e o evento PAI é disparado. O módulo USER_COMMAND_100 verifica o
campo OK_CODE e chama a tela 200.
No evento PBO da tela 200, a tabela interna LIST é preenchida com os valores da tabela
transparente SPFLI. O campo KEY é preenchido com os números do vôo, e as outras
informações relevantes são inseridas no campo TEXT. A tabela interna LIST é então, transferido
para o módulo de função VRM_SET_VALUES. Quando o usuário seleciona o campo de entrada
da tela 200, a coluna TEXT da tabela interna é apresentada na caixa de listagem. Quando o
usuário seleciona uma entrada, o campo da tela é preenchido com a entrada correspondente
do campo KEY, e o evento PAI é disparado. O módulo USER_COMMAND_200 verifica e
processa o campo OK_CODE.
57
Alterar as propriedades da tela dinamicamente
Os atributos da tela são definidos manualmente no Screen Painter. Entretanto, é possível

alterar os atributos dinamicamente em tempo de execução através de uma tabela interna
especial.
Definindo os atributos dinamicamente
Cada campo na tela tem um conjunto de atributos que são fixados na definição da tela no
Screen Painter. Na execução do programa ABAP, um subconjunto dos atributos para cada
campo da tela pode ser endereçado utilizando a tabela de sistema chamada SCREEN.
A tabela SCREEN
SCREEN é como uma tabela interna com a linha de cabeçalho. Entretanto, não é necessário
declará-lo no programa. Ele não pode ser apresentado no Debugger, e não pode utilizar
nenhuma work área a não ser a linha de cabeçalho endereçado a ele. Ele tem a seguinte
estrutura.
Tamanh
Componente o Tipo Descrição Atributo
NAME 132 CHA Nome do campo da tela Nome
R
GROUP1 3 CHA Grupo de modificação 1 Grupo 1
R
R
R
R
REQUIRED 1 CHA Campo de entrada é obrigatório Campo de entrada:
R Required
INPUT 1 CHA O campo está pronto para entrada Campo de entrada
R
OUTPUT 1 CHA O campo é somente de saída Campo de saída
R
INTENSIFIED 1 CHA O campo está destacado Visível
R
INVISIBLE 1 CHA O campo é invisível Invisível
R
LENGTH 1 RAW Tamanho do campo Compr.Vis.
ACTIVE 1 CHA O campo está ativo Campo de entrada/Campo
R de saíde/Invisível
DISPLAY_3D 1 CHA Caixa tridimensional Bidimensional
R
58
VALUE_HELP 1 CHA Apresenta o botão de ajuda de pesquisa Aj.p/pes
R
REQUEST 1 CHA Entrada existe --
R
VALUES_IN_COMB 1 CHA Caixa de listagem Dropdown
O R
COLOR 10 INT4 Definição de cor do campo --
A coluna “Atributo” contém os atributos correspondentes dos campos da tela no Screen
Painter.
59
As propriedades work area SCREEN podem ser modificadas no programa ABAP durante o
evento PBO da tela. O conteúdo da work area SCREEN irá sobre gravar os atributos estáticos
do campo da tela em uma simples chamada de tela. Os únicos comandos que podem ser
utilizados com a work area SCREEN são:
LOOP AT SCREEN.
...
MODIFY SCREEN.
...
ENDLOOP.
O comando LOOP AT SCREEN não pode ter nenhum parâmetro.
O componente NAME contém o nome do campo da tela. Os componentes GROUP1 até

GROUP4 podem conter qualquer código de caracteres de até três posições. Esses códigos
permitem a inclusão de campos de tela em até quatro grupos de modificação. Grupos de
modificação são como uma chave extra para a tabela SCREEN que permite a modificação dos
atributos de todos os elementos em um grupo simultaneamente. Os grupos de modificação
são atribuídos estaticamente no Screen Painter, porém podem ser sobre gravados
dinamicamente no programa.
Os componentes restantes são para leitura e ativação ou desativação dos atributos de

apresentação dos campos de tela. Para todos os componentes diferente de LENGTH e COLOR,
1 significa ativo e 0 significa inativo.
ACTIVE, INPUT, OUTPUT, e INVISIBLE
Há uma certa regra hierárquica entre os componentes ACTIVE, INPUT, OUTPUT e INVISIBLE.
Eles também tem diferentes efeitos dependendo de suas definições estáticas.
O componente ACTIVE não tem equivalente no atributo de elementos. Ao invés disso, ele
modifica os componentes INPUT, OUTPUT e INVISIBLE.
No início do PBO, ACTIVE está sempre definido como 1, independentemente da configuração

do atributo estático. Ao definir ACTIVE para 0, automaticamente define INPUT = 0, OUTPUT = 0
e INVISIBLE = 1. Qualquer outra definição em INPUT, OUTPUT e INVISIBLE na mesma linha da
tabela são ignoradas. Reciprocamente, definindo INPUT = 0, OUTPUT = 0 e INVISIBLE = 1,
define ACTIVE para 0 e qualquer outra definição em INPUT, OUTPUT e INVISIBLE na mesma
linha da tabela são ignoradas. A definição ACTIVE = 1 não tem outro efeito nos atributos. O
único propósito do componente ACTIVE é permitir que um campo seja definido como inativo
através de um simples comando.
Existem oito possíveis combinações para os componentes ACTIVE, INPUT, OUTPUT e INVISIBLE,
que tem os seguintes efeitos nos campos de tela:
60
ACTIVE INPUT OUTPUT INVISIBL Efeito
E
1 1 1 0 O campo é apresentado, mesmo que o atributo Invisible esteja
definidos estaticamente.
O conteúdo do campo é apresentado.
Pronto para entrada, mesmo se Input não for definido
estaticamente. Entretanto, não está pronto para entrada se Só
campo de saída estiver definido estaticamente.
1 1 0 0 O campo da tela é apresentado, mesmo se Invisible é definido
estaticamente, exceto quando Só campo de saída é definido
estaticamente.
O conteúdo do campo não é apresentado.
Pronto para entrada, mesmo que Input esteja definido
estaticamente.
estaticamente.
O conteúdo do campo é apresentado.
Não está pronto para entrada, mesmo se Input esteja definido
estaticamente.
estaticamente.
Não está pronto para entrada, mesmo se Input esteja definido
estaticamente.
estaticamente.
Pronto para entrada, mesmo se Input não estiver definido
estaticamente.
O valor inserido é mascarado com asterisco (*).
estaticamente.
O valor de saída é mascarado com asterisco (*).
Pronto para entrada, mesmo se Input não estiver definido
estaticamente.
O valor inserido é mascarado com asterisco (*).
1 0 1 1 O campo está inativo.
O campo não é apresentado, independentemente dos
atributos estáticos.
0 0 0 1 O campo está inativo.
O campo não é apresentado, independentemente dos
atributos estáticos.
Mascarar a entrada de valores pode ser utilizado para entrar senha de usuário.
61
Se uma linha inteira se torna invisível quando os campos se tornam invisíveis, a tela
automaticamente torna-se menor. Este
atributo pode ser desligado nos atributos
estático de tela selecionando a opção
Desativar compact.tmp.exec..
REQUIRED
Quando o componente Required é definido com o valor 1, o campo torna-se obrigatório. O

usuário só pode deixar a tela quando os campos mandatórios possuem valores. Exceção:
Códigos de função com tipo E e módulos com a adição AT EXIT-COMMAND.
DISPLAY_3D
Quando o componente Display_3D é definido com o valor 0, o quadro tridimensional do

campo entrada/saída é removido. O componente Display_3D não pode receber o valor 1 para
criar o efeito tridimensional para campos textos ou campos de tela com o atributo Só campo
de saída.
VALUE_HELP
Definindo o componente VALUE_HELP para 1 ou 0 alterna a ajuda de pesquisa para ligado e

desligado, respectivamente.
INTENSIFIED
Ao definir o valor do componente INTENSIFIED para 1, o conteúdo do campo de entrada é

alterado de preto para vermelho. O conteúdo dos campos de saída são alterados de preto para
azul.
62
LENGTH
O tamanho do componente pode ser definido para um valor menor do que o valor
estaticamente definido (Compr.Vis.) para campos de entrada/saída e campos só de saída.
REQUEST
Ao definir REQUEST = 1 para um campo de entrada tem o mesmo efeito no evento PAI como
se o usuário tivesse mudado o conteúdo do campo. Isto significa que uma chamada de módulo
condicional utilizando ON REQUEST ou ON CHAIN-REQUEST deveria ser executado
independentemente se o usuário alterou o valor do campo. REQUEST é automaticamente
definido para 0.
Exemplo:
REPORT demo_dynpro_modify_screen .
INCLUDE demo_dynpro_modify_screen_sel.
DATA: field1(10) TYPE c, field2(10) TYPE c, field3(10) TYPE c,
field4(10) TYPE c, field5(10) TYPE c, field6(10) TYPE c.
DATA: itab LIKE TABLE OF screen WITH HEADER LINE.
DATA length(2) TYPE c.
field1 = field2 = field3 = '0123456789'.
CALL SCREEN 100.
CLEAR: itab, itab[].
SET PF-STATUS 'SCREEN_100'.
IF save_ok = 'MODIFY'.
itab-name = text-001.
APPEND itab.
LOOP AT SCREEN.
IF screen-group1 = 'MOD'.
MOVE-CORRESPONDING screen TO itab.
APPEND itab.
ENDIF.
ENDLOOP.
PERFORM change_input CHANGING:
act, inp, out, inv, req, int, d3d, hlp, rqs.
63
CALL SELECTION-SCREEN 1100 STARTING AT 37 5.
PERFORM change_input CHANGING:
act, inp, out, inv, req, int, d3d, hlp, rqs.
MESSAGE s888(SABAPDOCU) WITH act inp out inv.
CLEAR itab.
APPEND itab.
LOOP AT SCREEN.
screen-active = act.
screen-input = inp.
screen-output = out.
screen-invisible = inv.
screen-required = req.
screen-intensified = int.
screen-display_3d = d3d.
screen-value_help = hlp.
screen-request = rqs.
screen-length = len.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
CLEAR itab.
itab-active = act.
itab-input = inp.
itab-output = out.
itab-invisible = inv.
itab-required = req.
itab-intensified = int.
itab-display_3d = d3d.
itab-value_help = hlp.
itab-request = rqs.
itab-length = len.
APPEND itab.
CLEAR itab.
APPEND itab.
ENDIF.
ENDMODULE.
LEAVE PROGRAM.
ENDMODULE.
save_ok = ok_code.
CLEAR ok_code.
CASE save_ok.
WHEN 'MODIFY'.
LEAVE TO SCREEN 100.
WHEN 'LIST'.
CLEAR itab.
APPEND itab.
64
LOOP AT SCREEN.
MOVE-CORRESPONDING screen TO itab.
APPEND itab.
ENDIF.
ENDLOOP.
CALL SCREEN 200 STARTING AT 37 5
ENDING AT 87 22.
ENDCASE.
ENDMODULE.
MODULE requested INPUT.
MESSAGE s888(sabapdocu) WITH text-004.
ENDMODULE.
SUPPRESS DIALOG.
LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN 0.
FORMAT COLOR COL_HEADING ON.
WRITE: 10 'ACT', 14 'INP', 18 'OUT', 22 'INV', 26 'REQ',
30 'INT', 34 'D3D', 38 'HLP', 42 'RQS', 46 'LEN'.
FORMAT COLOR COL_HEADING OFF.
ULINE.
LOOP AT itab.
IF itab-name = ' '.
ULINE.
ELSEIF itab-name = text-001 OR itab-name = text-003.
FORMAT COLOR COL_NORMAL ON.
ELSE.
FORMAT COLOR COL_NORMAL OFF.
ENDIF.
len = itab-length.
length = ' '.
IF len NE 0.
length = len.
ENDIF.
WRITE: /(8) itab-name,
11 itab-active,
15 itab-input,
19 itab-output,
23 itab-invisible,
27 itab-required,
31 itab-intensified,
35 itab-display_3d,
39 itab-value_help,
43 itab-request,
47 length.
ENDLOOP.
ENDMODULE.
FORM change_input CHANGING val TYPE any.
IF val = 'X'.
65
val = '1'.
ELSEIF val = ' '.
val = '0'.
ELSEIF val = '1'.
val = 'X'.
ELSEIF val = '0'.
val = ' '.
ENDIF.
ENDFORM.
A tela 100 tem o seguinte leiaute:
66
Subtelas
As subtelas permitem que uma ou mais telas sejam embutidas em uma tela. O termo subtela
aplica-se para a tela embutida e a área na tela principal na qual ela é inserida. Esta seção
refere-se a áreas de subtelas. Quando uma subtela é utilizada, a lógica de processamento da
subtela também é embutida na lógica de processamento da tela principal.
As subtelas permitem expandir o conteúdo de uma tela em tempo de execução. Por exemplo,
screen exits, que faz parte do conceito de ampliação, utiliza a técnica de subtela. O controle de
ficha também o utiliza.
Para utilizar uma subtela, é necessário:
1. Definir a área de subtela na tela principal

2. Criar a tela e defini-la como subtela
3. Associar a subtela na área de subtela
67
Definindo a área de subtela na tela principal
A área de subtela é definida no screen painter na área de leiaute na qual será

embutida a subtela. Cada área de subtela possuirá um nome único, uma posição, altura e
largura. A área de subtela não pode ser sobreposta sobre os outros elementos de tela.
1. Clicar no botão “Área

de subtela” na palheta
de elementos.
2. Adicionar a área de
subtela na tela.
3. Definir o nome da área
de subtela.
Criar a subtela
A subtela pode ser criada no mesmo programa ou num programa externo. Para criar uma
subtela, é necessário:
1. Definir a tela como subtela
68
2. O campo “Tela Seguinte” deve ter o mesmo número da subtela criada
O leiaute, os elementos e a lógica de processamento são os mesmos de uma tela normal.

Subtelas também podem conter outras subtelas. Entretanto, as seguintes regras aplicam-se:
 Os elementos da tela devem ser organizados para que eles não sejam truncados se a
área de subtela é muito pequena.
 Se várias subtelas serão criadas no programa, os nomes dos elementos contidos nas
subtelas devem ser únicos entre as subtelas.
 Subtelas não possuem o campo OK_CODE. O código de função utilizado nas subtelas
são os códigos de função herdados da tela principal.
 A lógica de processamento da subtela não pode conter o comando MODULE ... AT
EXIT-COMMAND. Os códigos de função tipo E só podem ser manipulados na tela
principal.
 A lógica de processamento da subtela não pode conter nenhum módulo de diálogo
com os comandos SET TITLEBAR, SET PF-STATUS, SET SCREEN, LEAVE SCREEN ou LEAVE
TO SCREEN. Quaisquer uns desses comandos causam um erro de execução. O status
GUI da tela principal não pode ser modificado pela subtela.
Associar a subtela na área de subtela
Para associar uma subtela a uma área de subtela deve-se utilizar o comando CALL SUBSCREEN
na lógica de processamento da tela principal.
Para incluir uma subtela na área de subtela da tela principal e chamar a sua lógica do fluxo do
PBO, o seguinte comando no evento PBO deve ser utilizado:
PROCESS BEFORE OUTPUT

...
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.
Este comando atribui a subtela <dynp> com a área de subtela chamada <area>. Também é
possível especificar o programa no qual a tela é definida (opcional). Se o programa não for
especificado explicitamente, o sistema procura a subtela no mesmo programa da tela
principal. Se a subtela não for encontrada, um erro de execução é apresentado. O fluxo do PBO
da subtela também está incluída no mesmo ponto.
O nome <area> da subtela deve ser definida diretamente sem aspas. Os nomes <prog> e
<dynp> podem ser literais ou variáveis. Se for utilizado variável, a mesma deve ser declarada
69
com o mesmo nome no programa ABAP. O número de tela deve ser do tipo CHAR de 4
posições.
Para chamar o evento PAI da subtela, o seguinte comando no evento PAI da tela principal deve
ser utilizado:
PROCESS AFTER INPUT

...
CALL SUBSCREEN <area>.
...
Este comando inclui o fluxo de evento PAI da subtela na área de subtela no evento PBO.
O comando CALL SUBSCREEN não pode ser utilizado dentro dos comandos CHAIN e ENDCHAIN
ou LOOP e ENDLOOP. Enquanto uma subtela estiver sendo processada, o campo de sistema
SY-DYNNR contém o número da subtela.
Os códigos de função das ações dos usuários na tela são sempre inseridos no campo OK-CODE
da tela principal, e transportado no programa no qual está definido. Os códigos de função a
serem utilizados na subtela deverão ser diferentes da tela principal.
Se, por motivos de encapsulamento, as subtelas forem definidas em outro programa ABAP, é
necessário garantir que todos os dados globais utilizados pela subtela deverão ser
transportados para o programa que a subtela reside, depois de ter chamado o fluxo de evento
PAI.
Exemplo:
REPORT demo_dynpro_subscreens.
DATA: number1(4) TYPE n VALUE '0110',
number2(4) TYPE n VALUE '0130',
field(10) TYPE c, field1(10) TYPE c, field2(10) TYPE c.
CALL SCREEN 100.
ENDMODULE.
MODULE fill_0110 OUTPUT.
field = 'Eingabe 1'(001).
ENDMODULE.
field = field1.
70
ENDMODULE.
field = 'Eingabe 2'(002).
ENDMODULE.
field = field2.
ENDMODULE.
LEAVE PROGRAM.
ENDMODULE.
MODULE save_ok INPUT.
save_ok = ok_code.
CLEAR ok_code.
ENDMODULE.
IF save_ok = 'OK1'.
number1 = '0120'.
field1 = field.
CLEAR field.
ENDIF.
ENDMODULE.
IF save_ok = 'OK2'.
number2 = '0140'.
field2 = field.
CLEAR field.
ENDIF.
ENDMODULE.
CASE save_ok.
WHEN 'SUB1'.
number1 = '0110'.
WHEN 'SUB2'.
number1 = '0120'.
CLEAR field1.
WHEN 'SUB3'.
number2 = '0130'.
WHEN 'SUB4'.
number2 = '0140'.
CLEAR field2.
ENDCASE.
ENDMODULE.
71
A tela seguinte para a tela 100 é ela mesmo. Ela possui o seguinte leiaute:
Há quatro botões com os códigos de função SUB1 a SUB4 e duas áreas de subtelas AREA1 e
AREA2.
No mesmo programa ABAP, há quatro subtelas 100 a 140. Cada uma delas se ajustam
exatamente à área de subtela.
Ao executar o programa, uma tela aberta onde as subtelas 110 e 130 são apresentadas. Os
botões da tela principal permitem a escolha entre duas subtelas para cada área de subtela. Os
botões das subtelas permitem transferir os dados das subtelas 110 e 130 para as subtelas 120
e 140.
72
Controle de Fichas
Um controle de fichas é um objeto de tela que possui duas ou mais abas. Cada aba possui um
título e uma área.
O controle de fichas permite a inserção de uma série de telas pertencentes a uma aplicação
em uma única tela e a navegação entre elas facilmente.
Do ponto de vista técnico, uma aba é uma subtela com um botão atribuído a ele, a qual é
apresentada como título da aba.
O controle de fichas é o conjunto de todas as abas e estão sujeitos as mesmas restrições das
subtelas. Em particular, não é possível alterar o status GUI quando as abas são ativas no
controle de fichas. Entretanto, eles são completamente integrados no ambiente de telas.
Ao criar um controle de fichas, é necessário:

1. Definir a área na tela e os títulos da aba;
2. Atribuir uma área de subtela para cada aba;
3. Programa o fluxo de processamento da tela;
4. Programar o processamento lógico ABAP.
Definindo a área do controle de fichas e os títulos das abas
A área do controle de fichas e o título das abas são definidos no Screen Painter.
A área do controle de fichas tem um nome único e uma posição, largura e altura.
73
Quando a área do controle de fichas é
definida, ele já possui duas abas.
As abas são exatamente iguais aos

botões. Para criar abas adicionais,
simplesmente crie os botões na linha
contendo os títulos das abas.
As abas possuem as mesmas

propriedades dos botões, como nome,
texto e código de função. Ícones de
textos dinâmicos podem ser utilizados
como título das abas.
Atribuindo uma área de subtela a uma aba
Há dois modos de atribuir uma área de subtela a uma aba:
Paginação no SAPgui
Uma área de subtela é definida para cada aba, e os códigos de função das abas são definidas
com o tipo P (Local GUI Function). Na lógica de processamento, todas as subtelas são
chamadas no evento PBO. Isto significa que todas as abas residem localmente no SAPgui.
Quando o usuário seleciona uma aba, a paginação é ativado dentro do SAPgui. A este respeito,
o controle de fichas se comporta como uma simples tela. Em particular, o evento PAI não é
disparado quando o usuário seleciona uma aba e nenhum dado é transportado. Enquanto esse
método melhora o desempenho do controle de ficha, ele também tem o lado negativo que
quando o usuário dispara o evento PAI, todas as verificações de entrada para todas as subtelas
são executadas. Isto significa que quando o usuário estiver trabalhando em uma aba, a
verificação de entrada poderá pular para um campo mandatório em outra aba.
74
Paginação local no SAPgui é o mais apropriado para telas que apresentam os dados ao invés de
telas que permitem a edição dos dados.
Paginação no servidor de aplicação
Uma área de subtela é compartilhada por todas as abas e chamado no evento PBO. Os códigos
de função das abas são definidos sem um tipo especial função. Quando o usuário seleciona
uma aba, o evento PAI é disparado, e um módulo é incluído na lógica de processamento para
ativar a aba apropriada e atribui a subtela correta a área de subtela.
Desde o evento PAI é acionado cada vez que o usuário escolhe uma aba, este método é menos
econômico para o servidor de aplicação, mas as verificações de entrada que são executadas só
afetam a aba atual.
Procedimento em ambos os casos
As áreas de subtela são criadas dentro das áreas das abas. As áreas de subtelas são atribuídas
para uma ou mais abas no Screen
Painter selecionando uma ou mais
abas.
Se a paginação for pelo SAPgui, é

necessário criar uma área de subtela
para cada aba. Se a paginação for no
servidor de aplicação, selecione todas
as abas e crie uma única área de
subtela.
Programando a lógica de processamento
Na lógica de processamento, tudo que deve ser feito é incluir a subtela correta. O fluxo de
telas e o transporte de dados para o programa ABAP são os mesmos das subtelas normais. Há
dois modos de programar a lógica de processamento:
Paginação no SAPgui
Na paginação pelo SAPgui, cada área de subtela deve ser atribuída a uma subtela:
75
...
CALL SUBSCREEN: <area1> INCLUDING [<prog1>] <dynp1>,
<area2> INCLUDING [<prog2>] <dynp2>,
<area3> INCLUDING [<prog3>] <dynp3>,
...
...
...
CALL SUBSCREEN: <area1>,
<area2>,
<area3>,
Paginação no servidor de aplicação
Ao paginar no servidor de aplicação, só é necessário incluir uma subtela para cada uma das
áreas de subtela.

...
CALL SUBSCREEN <area> INCLUDING [<prog>] <dynp>.
...

...
CALL SUBSCREEN <area>.
Editado o programa ABAP
Antes de criar um controle de fichas no programa ABAP, é necessário criar um objeto controle
para cada controle de ficha na parte de declaração do programa ABAP utilizando o seguinte
comando:
CONTROLS <ctrl> TYPE TABSTRIP.
Onde <ctrl> é o nome do controle de ficha na tela do programa ABAP. O controle permite que
o programa ABAP trabalhe com o controle de ficha. O comando declara uma estrutura com o
nome <ctrl>. O único componente que poderá ser utilizado no programa é o ACTIVETAB.
 Uso no evento PBO

Antes da tela ser apresentada, o controle é utilizado para definir a aba ativa. Para isto,
atribua o código de função da aba correspondente para o componente ACTIVETAB.
<ctrl>-ACTIVETAB = <fcode>.
76
Ao pagina no SAPgui, é necessário realizar esse procedimento antes da tela ser
apresentada ao usuário. Isto faz com que o controle de fichas seja reinicializado. A aba
padrão é a primeira aba. Depois disso, a aba ativada pelo usuário é definida no SAPgui.
Quando a paginação é realizada no servidor de aplicação, a aba selecionada deve ser

ativada antes de apresentar a tela ao usuário e a cada vez que a aba é selecionada. Ao
mesmo tempo, a subtela deve ser definida.
 Uso no evento PAI

No evento PAI, ACTIVETAB possui contém o código de função da última aba ativa na
tela.
Quando a paginação ocorre no SAPgui, é possível saber a última aba selecionada pelo
usuário. Se a paginação ocorrer no servidor de aplicação, a aba ativa é controlada pelo
programa ABAP.
O campo OK_CODE age de formas diferentes de acordo com o método de paginação:
 Paginação no SAPgui
O evento PAI não é disparado quando o usuário seleciona uma aba, e o campo
OK_CODE não é preenchido. O campo OK_CODE só receberá um valor caso o usuário
clique em alguma ação do Status GUI ou quando um botão fora do controle de fichas
ou dentro forem selecionados.
 Paginação no servidor de aplicação

O evento PAI é disparado quando o usuário seleciona uma aba e o campo OK_CODE
recebe o valor do código de função correspondente.
Para paginas através das abas do controle de fichas, o código de função deve ser
atribuído ao componente ACTIVETAB do controle.
<ctrl>-ACTIVETAB = <ok_code>.
Exemplo:
Controle de fichas utilizando a paginação no SAPgui
REPORT demo_dynpro_tabstrip_local.
CONTROLS mytabstrip TYPE TABSTRIP.
mytabstrip-activetab = 'PUSH2'.
CALL SCREEN 100.
77
ENDMODULE.
LEAVE PROGRAM.
ENDMODULE.
MODULE user_command INPUT.
save_ok = ok_code.
CLEAR ok_code.
IF save_ok = 'OK'.
MESSAGE i888(sabapdocu) WITH 'MYTABSTRIP-ACTIVETAB ='
mytabstrip-activetab.
ENDIF.
ENDMODULE.
A tela 100 tem o seguinte leiaute:
78
A tela contém uma área de controle de fichas chamada MYTABSTRIP
com três abas PUSH1, PUSH2, PUSH3. Os códigos de função
possuem o mesmo nome das abas e todas foram definidas com o
tipo P. Cada uma das áreas de subtela SUB1 a SUB3 estão associadas
a cada aba. O botão “Avançar” possui o nome BUTTON e o código
de função ‘OK’.
No mesmo programa ABAP, há três subtelas 110 a 130.
A lógica de processamento da tela 100 é:
MODULE STATUS_0100.
CALL SUBSCREEN: SUB1 INCLUDING SY-REPID '0110',
SUB2 INCLUDING SY-REPID '0120',
SUB3 INCLUDING SY-REPID '0130'.
CALL SUBSCREEN: SUB1,
SUB2,
SUB3.
MODULE USER_COMMAND.
A lógica de processamento das subtelas 110 a 130 não possuem código.
Quando o programa é executado, a tela aparece com a segunda aba ativa, desde que o
programa defina o componente ACTIVETAB da estrutura MYTABSTRIP para PUSH2 antes da
tela ser apresentada. O usuário poderá paginar através do controle de fichas sem o evento PAI
ser disparado.
Quando o usuário pressiona o botão “CONTINUE”, o evento PAI é disparado e uma mensagem
de informação apresenta o código de função da guia ativa.
79
Table Control
O ABAP fornece um mecanismo de visualizar e utilizar dados tabulares na tela. Este mecanismo
é o table control. Table control é um tipo de tabela que pode ser adicionado na tela através do
Screen Painter. Por exemplo, a tela abaixo contém uma table control.
Utilizando o comando LOOP
O comando de tela LOOP... ENDLOOP permite a execução das operações de laço na lógica de
processamento da tela. Este comando pode ser utilizado para executar um loop na table
control. Entre o comando LOOP e ENDLOOP, os comandos FIELD, MODULE, SELECT, VALUES e
CHAIN podem ser utilizados. Na maioria dos casos, o comando MODULE é utilizado para
chamar um módulo ABAP.
O comando LOOP deve ser codificado nos eventos PBO e PAI para cada tabela na tela. Isso faz
com que o comando LOOP faz com que os valores dos campos da tela e do ABAP sejam
transferidos de um para o outro e vice-versa. Por esta razão, o comando LOOP...ENDLOOP
deve ser utilizado, mesmo que vazio.
O comando LOOP tem a seguinte forma:
80
81
LOOP AT <tabela interna>.
Este comando executa o loop através de uma tabela interna e o table control da tela de em
paralelo. Os campos da table control geralmente são, mas não é obrigatório, declarados como
campos de tabela interna.
Em particular, o comando LOOP AT, executa o loop através de um porção da tabela interna
que está atualmente visível na tela.
A sintaxe completa do comando LOOP é:
LOOP AT <tabela interna> CURSOR <scroll-var>

[WITH CONTROL <table control>].
...<ações>...
ENDLOOP.
Esta forma do comando LOOP AT, realiza o loop através da tabela interna, executando <ações>
para cada linha. Para cada linha da tabela interna, o sistema transfere os campos relevantes do
programa para ou da linha correspondente da table control.
Exemplo: Transação TZ60
A transação TZ60 é um exemplo de programação com table control. Ele apresenta as

informações de vôo em duas telas. Na primeira tela, o usuário informa uma conexão de vôo e
solicita as informações detalhadas. Na segunda tela (tela 200), a transação apresenta todos os
vôos agendados para a conexão.
82
Há duas coisas importantes para serem notadas neste programa:
 Como os dados da tela são obtidos e repassados
Os campos da table control são declarados como campos de tabelas (tabela SFLIGHT)
no programa ABAP. Para armazenar vários registros da SFLIGHT de uma única vez, o
programa utiliza a tabela interna INT_FLIGHTS.
1. Durante a execução do evento PAI da tela 100, o programa seleciona todos os dados
de vôo da conexão informada e os armazena na tabela interna INT_FLIGHTS.
2. No evento PBO da tela 200, o comando LOOP executa o loop na tabela interna
INT_FLIGHTS, chamando o módulo DISPLAY_FLIGHTS para cada linha.
DISPLAY_FLIGHTS, por sua vez, transfere uma linha da INT_FLIGHTS para a work area
SFLIGHTS. Os campos da SFLIGHT são iguais dos nomes da table control, então para
cada laço do loop, o sistema transfere os valores do ABAP para os campos da table
control na tela 200.
o Uso dos campos da table control para controlar a rolagem
A table control contém informações para gerenciar a rolagem. Isto inclui

campo dizendo quantas linhas da tabela estão preenchidas e qual linha da
tabela deve ser a primeira a ser mostrada na tabela. O sistema gerencia a
rolagem da tabela automaticamente. Isto inclui a rolagem da tela corrente,
bem como a reinicialização das variáveis de rolagem. Entretanto, o programa
de exemplo oferece rolagem com os botões de paginação ( ).
Neste caso, o programa deve ter implementado estas funções explicitamente.
1. Durante o evento PAI da tela 100, o programa inicializa a variável TOP_LINE para 1. A
variável TOP_LINE indica qual é a primeira linha a ser apresentada na table control.
2. No evento PAI da tela 200, o programa reinicializa as variáveis de rolagem,
especialmente o campo TOP_LINE, caso o usuário tenha utilizado a rolagem com os
botões de paginação ( )
Lógica de processamento da tela 200
A lógica de processamento para a tela 200 na transação TZ60 é:
MODULE STATUS_0200.
LOOP AT INT_FLIGHTS WITH CONTROL FLIGHTS CURSOR FLIGHTS-TOP_LINE.
MODULE DISPLAY_FLIGHTS.
ENDLOOP.
*
*
83
LOOP AT INT_FLIGHTS.
MODULE SET_LINE_COUNT.
ENDLOOP.
Código ABAP
A seção seguinte do código do módulo TOP mostra as definições relevantes ao seguinte

código:
*---------------------------------------------------------------------
* INCLUDE MTZ40TOP
*---------------------------------------------------------------------
PROGRAM SAPMTZ60 MESSAGE-ID A&.
TABLES: SFLIGHT, " Flights
SPFLI, " Flight data
SAIRPORT, " Check: Airports
SCARR. " Airlines
DATA: OK_CODE(4),
RCODE(5),
LINE_COUNT TYPE I.
CONTROLS: FLIGHTS TYPE TABLEVIEW USING SCREEN 200.
DATA INT_FLIGHTS LIKE SFLIGHT OCCURS 1 WITH HEADER LINE.
O módulo no evento PBO transfere os dados dos campos da tabela interna para os campos da
table control:
*&--------------------------------------------------------------------
*& Module DISPLAY_FLIGHTS OUTPUT
*&--------------------------------------------------------------------
MODULE DISPLAY_FLIGHTS OUTPUT.
SFLIGHT-FLDATE = INT_FLIGHTS-FLDATE.
SFLIGHT-PRICE = INT_FLIGHTS-PRICE.
SFLIGHT-CURRENCY = INT_FLIGHTS-CURRENCY.
SFLIGHT-PLANETYPE = INT_FLIGHTS-PLANETYPE.
SFLIGHT-SEATSMAX = INT_FLIGHTS-SEATSMAX.
SFLIGHT-SEATSOCC = INT_FLIGHTS-SEATSOCC.
ENDMODULE. " DISPLAY_FLIGHTS OUTPUT
No evento PAI, o programa deve executar o loop novamente para transferir os campos da
table control de volta para o programa. Durante o LOOP o programa utiliza a variável de
sistema SY-LOOPC para descobrir quantas linhas foram transferidas. SY-LOOPC é uma variável
de sistema que informa o número total de linhas sendo apresentado no table control.
84
*&--------------------------------------------------------------------
*& Module SET_LINE_COUNT INPUT
*&--------------------------------------------------------------------
* text
*
*---------------------------------------------------------------------
MODULE SET_LINE_COUNT INPUT.
LINE_COUNT = SY-LOOPC.
ENDMODULE. " SET_LINE_COUNT INPUT
A transação TZ60 permite que o usuário pressione os botões de paginação ( )

para rolar a tabela. O sistema manipula a rolagem da barra de rolagem automaticamente, mas
não para rolagem com códigos de função (botões de paginação). Então no evento PAI da tela
200, a funcionalidade de rolagem deverá ser implementada explicitamente.
MODULE USER_COMMAND_0200 INPUT.
CASE OK_CODE.
WHEN 'CANC'.
CLEAR OK_CODE.
SET SCREEN 100. LEAVE SCREEN.
WHEN 'EXIT'.
CLEAR OK_CODE.
WHEN 'BACK'.
CLEAR OK_CODE.
WHEN 'NEW'.
CLEAR OK_CODE.
WHEN 'P--'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P--'.
WHEN 'P-'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P-'.
WHEN 'P+'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P+'.
WHEN 'P++'.
CLEAR OK_CODE.
PERFORM PAGING USING 'P++'.
ENDCASE.
ENDMODULE. " USER_COMMAND_0100 INPUT
A rotina PAGING faz com que o sistema role a tabela definindo o campo de controle TOP_LINE
para um novo valor. O campo TOP_LINE avisa o comando LOOP onde começar a executar o
laço no evento PBO.
85
*&--------------------------------------------------------------------
*& Form PAGING
*&--------------------------------------------------------------------
* text
*
*---------------------------------------------------------------------
FORM PAGING USING CODE.
DATA: I TYPE I,
J TYPE I.
CASE CODE.
WHEN 'P--'. FLIGHTS-TOP_LINE = 1.
WHEN 'P-'. FLIGHTS-TOP_LINE = FLIGHTS-TOP_LINE - LINE_COUNT.
IF FLIGHTS-TOP_LINE LE 0. FLIGHTS-TOP_LINE = 1. ENDIF.
WHEN 'P+'. I = FLIGHTS-TOP_LINE + LINE_COUNT.
J = FLIGHTS-LINES - LINE_COUNT + 1.
IF J LE 0. J = 1. ENDIF.
IF I LE J. FLIGHTS-TOP_LINE = I.
ELSE. FLIGHTS-TOP_LINE = J.
ENDIF.
WHEN 'P++'. FLIGHTS-TOP_LINE = FLIGHTS-LINES - LINE_COUNT + 1.
IF FLIGHTS-TOP_LINE LE 0. FLIGHTS-TOP_LINE = 1. ENDIF.
ENDCASE.
ENDFORM. " PAGING
Transferência de valores entre a tela e o programa ABAP
Com o comando LOOP AT <tabela interna>, a tabela de tela precisa ser declarada como tabela
interna. As tabelas de tela também podem ser tabelas de banco de dados, estruturas ou outros
campos de programas. Se a tabela de tela não for definida com uma tabela interna, é
necessário verificar se os campos corretos estão sendo movidos de e para o cabeçalho da
tabela interna durante o loop.
Os campos que são utilizados no table control podem ser somente um subconjunto dos
campos de tabelas do dicionário de dados ou de tabelas internas. O sistema transfere os
campos conforme o necessário para a table control.
Detalhes do processamento:
 Processamento do evento PBO

1. Uma linha da tabela interna é inserida no cabeçalho da tabela interna.
2. Todos os comandos de loop são executados para aquela linha.
Os comandos de loop possuem frequentemente chamadas para os módulos

de ABAP. Quando necessário, estes módulos devem mover os valores dos
campos da tabela interna para os campos relevantes do programa (tabela do
dicionário ou outros campos).
86
Como exemplo é a transação TZ60 que faz isso na rotina DISPLAY_FLIGHTS
MODULE DISPLAY_FLIGHTS OUTPUT.
SFLIGHT-FLDATE = INT_FLIGHTS-FLDATE.
SFLIGHT-PRICE = INT_FLIGHTS-PRICE.
SFLIGHT-CURRENCY = INT_FLIGHTS-CURRENCY.
SFLIGHT-PLANETYPE = INT_FLIGHTS-PLANETYPE.
SFLIGHT-SEATSMAX = INT_FLIGHTS-SEATSMAX.
SFLIGHT-SEATSOCC = INT_FLIGHTS-SEATSOCC.
ENDMODULE. " DISPLAY_FLIGHTS OUTPUT
3. O sistema transfere os valores dos campos do programa para os campos da

tela com os mesmos nomes.
 Processamento do evento PAI

4. Uma linha da tabela interna é inserida no cabeçalho da tabela interna.
5. Todos os campos da table control são transferidos para os campos do
programa ABAP de mesmo nome.
6. Todas as <ações> do loop são executadas para o registro corrente da tabela
interna.
Novamente, <ações> é geralmente uma chamada para o módulo ABAP.

Quando necessário esse módulo deve primeiramente mover os valores dos
campos de programa para o cabeçalho da tabela interna. Este passo, substitui
os valores da tabela interna com os da tela. O passo 1 é necessário para casos
onde os campos da tela são somente um subconjunto dos campos definidos
para a tabela interna. Se for necessário atualizar a tabela interna com novos
valores da tela, é preciso ter o registro original como base no cabeçalho da
tabela interna.
Observação: Para atualizar o conteúdo da tabela interna com o conteúdo do

cabeçalho da tabela interna é necessário utilizar o comando MODIFY. O
sistema não faz essa atualização automaticamente.
87
Criação do programa ZCADMAT
Entrar na transação SE80:
Selecionar na caixa de seleção a opção

programa e inserir o nome do programa
ZCADMAT, que é o programa a ser
criado e teclar Enter.
Confirmar a criação do objeto, clicando no

botão ‘Sim’.
Confirmar a criação da include TOP.

A include TOP irá conter as declarações dos
objetos utilizados pelo programa, tais como
variáveis, work areas e tabelas internas.
Inserir o nome da include TOP com o

mesmo nome do programa, acrescido
do sufixo _TOP.
Clique no botão ‘Gravar’.

Obs.: O campo título,
diferentemente de um programa
do tipo Report, não tem
funcionalidade no programa do
tipo module-pool.
88
Informe o pacote que o programa fará
parte e clique no botão ‘Salvar’.
Informe a change request que o programa

deverá ser gravado e confirme.
Após as etapas anteriores, o programa será criado e apresentado conforme a figura 1.1:
Figura 1.1
89
Criação das Includes
O próximo passo é criar as includes que irão conter os códigos dos módulos PBO, PAI e das
sub-rotinas FORMS. Para isso, dê um duplo clique no nome do programa, que é o primeiro nó
da árvore de hierarquia do programa. Ao dar o duplo clique, o editor ABAP é aberto no lado
direito da janela, conforme a figura 1.2:
Figura 1.2
O programa possui uma chamada para a include TOP (ZCADMAT_TOP) e mais três chamadas
de includes de forma comentada. As três includes possuem os sufixos O01, I01 e F01. A lógica
de utilização dessas três includes é:
INCLUDE _O01: Nessa include irão conter todos os módulos PBO das telas do programa.
INCLUDE _I01: Nessa include irão conter todos os módulos PAI das telas do programa.
INCLUDE _F01: Nessa include irão conter todas as sub-rotinas FORM do programa.
O próximo passo é criar as três includes para fazer parte do programa. Para isso, será
necessário colocar o código ABAP em modo de edição clicando no botão “Exibir <-> Modificar”
ou utilizar a tecla de atalho CTRL+F1 e remover os asteriscos das linhas das três includes,
de forma que as linhas sejam descomentadas, conforme a figura 1.3.
90
Figura 1.3
Só o fato de descomentar as includes não significa que as mesmas podem ser utilizadas. Ainda
é necessário criá-las, dando o duplo clique no nome da include. Ao fazer isso, o sistema pede a
confirmação da criação do objeto conforme a figura abaixo:
Clique em ‘Sim’ para confirmar.
A janela de características será apresentada

e será necessário clicar no botão ‘Gravar’.
Ao gravar, o sistema irá solicitar novamente
o pacote e a change request. Utilize os
últimos utilizados.
Sempre que algum objeto solicitar pacote e request, utilize os mesmos que foram definidos no
programa, de modo a evitar de ter objetos espalhados em várias change requests e dificultar o
controle.
Após a gravação, o editor ABAP estará aberto na include recém criada, conforma a figura 1.4.
91
Figura 1.4
Salve o código, clicando no botão salvar da barra de ferramentas, mesmo que não tenha
nada, para que o programa include seja gravado.
Retorne para o programa principal utilizando o botão de voltar ou a tecla de atalho ‘F3’.
Faça o mesmo procedimento para os includes I01 e F01.
Após a criação de todas as includes, ative o programa ZCADMAT e suas respectivas includes da
seguinte forma:
Volte para o código fonte do programa principal, dando o duplo clique no nome do programa
na árvore hierárquica do programa. Isso
irá fazer com que o código fonte do
programa ABAP seja carregado. Se o
código estiver editável, alterne para visualização clicando no botão “Exibir <-> Modificar”
ou utilizar a tecla de atalho CTRL+F1.
Com o código em modo de visualização, clique

com o botão direito no nome do programa na
árvore hierárquica. Uma janela de pop-up será
apresentada e então selecione a opção ‘Ativar’.
92
Todos os objetos inativos do programa ZCADMAT estarão marcados para a ativação, conforme
a figura 1.5. Confirme a ativação clicando no botão ‘Avançar’ ou teclando ‘Enter’.
Figura 1.5
Todos os objetos estão ativos. Note que os objetos, no caso as includes e o programa,
possuem os nomes com a fonte na cor preta, o objeto inativo a cor da fonte é azul.
Objetos Ativos (nomes na cor preta) Objeto inativo (nome na cor azul)
93
Criação da tela 100
A tela 100 será a tela principal do nosso programa. A tela irá possuir campos de entrada e
saída, texto de título e botão, conforme a imagem abaixo:
94
Para criar uma nova tela, clique com o
botão direito no nome do programa e
na janela de pop-up que é
apresentado, selecione a opção Criar -
> Tela.
Insira o número da tela (0100) e

clique no botão ‘Avançar’ ou
tecle Enter.
Obs.: O valor pode ser de ‘0001’ a
‘9999’.
Na aba ‘Características’, preencha

o campo ‘Descrição breve’ e
defina o tipo de tela como
‘Normal’ e salve a tela .
95
Adicionando elementos na tela 100
Para adicionar os objetos na tela, tais como campos de entrada/saída, títulos, botões de rádio,
etc, e definir o leiaute da tela, é necessário utilizar o Screen Painter.
Clique no botão Layout na barra de botões para abrir o Screen Painter.
O Screen Painter possui os seguintes componentes:
1. Palheta de elementos
2. Barra de propriedades
3. Área de trabalho
4. Janela de atributos 4
96
4. Janela de atributos
A janela de atributos irá conter os atributos de um

determinado objeto selecionado.
Observação: Quando os elementos são adicionados na área de trabalho, eles ficam na cor
vermelha. Isso indica que determinados atributos do elemento devem ser preenchidos. Se
houver algum elemento especificado de forma incompleta, não será possível ativar a tela.
97
Os elementos a serem criado na tela 0100 estão especificados na tabela 1.1.
Tabela 1.1
I Elemento Nome Texto Campo de Só Código de Ícone
D entrada Campo Função
de saída
1 Campo Texto LFA1-LIFNR Fornecedor
2 Campo Entrada/Saída LFA1-LIFNR Sim
3 Campo Entrada/Saída LFA1-NAME1 Não Sim
ICON_OPE
4 Botão PB_ABRIR_100 Abrir FN_ABRIR N
A disposição dos elementos na área de trabalho deverá ficar conforme a figura 1.5.
Figura 1.5
1 2 3
Criar campo texto – LFA1-LIFNR
Na palheta de elementos, clicar no botão de campo de texto e adicionar na área de

trabalho.
Preencha o valor ‘LFA1-LIFNR’ no campo
‘Nome’ e tecle Enter. Ao teclar Enter, o
sistema irá perguntar se você quer
referenciar o campo ao dicionário ABAP.
Ao confirmar, o texto do campo texto
irá herdar o título presente no elemento
de dados do campo LIFNR da tabela
LFA1. Caso não deseje utilizar a referência, o texto deverá ser inserido manualmente. No nosso
caso, como estamos utilizando um objeto do dicionário ABAP, vamos confirmar, clicando no
botão ‘Sim’.
O resultado do campo de texto inserido na área de trabalho ficou da seguinte forma:
98
Criar campo de entrada/saída – LFA1-LIFNR
Na palheta de elementos, clicar no botão de campo

entrada/saída e adicionar na área de trabalho, logo à
frente do campo de texto.
Clique no campo de entrada/saída e defina o nome do campo com o valor ‘LFA1-LIFNR’ e tecle
‘Enter’. Novamente o sistema irá solicitar uma ação do desenvolvedor para confirmar a
referência do campo de entrada/saída com o campo LIFNR da tabela LFA1 do dicionário ABAP.
Clique no botão ‘Sim’ para confirmar.
Por se tratar de um campo de entrada/saída, todas as

características técnicas presentes no campo LIFNR da tabela LFA1,
serão copiadas para o campo entrada/saída LFA1-LIFNR,
conforme a janela de atributos indicada ao lado.
No nosso exemplo, os campos ‘Exit Conversão’ e ‘ID parâmetro’

foram obtidos do dicionário de dados. O campo checkbox
chamado ‘Do Dict’ está marcado, indicando que o campo de
entrada/saída está referenciado ao dicionário ABAP.
Criar campo de entrada/saída – LFA1-NAME1
Na palheta de elementos, clicar no botão de campo entrada/saída

e adicionar na área de trabalho, logo à frente do campo de
texto.
Clique no campo de entrada/saída e defina o nome do campo com o

valor ‘LFA1-NAME1’ e tecle enter. Novamente o sistema irá solicitar
uma ação do desenvolvedor para confirmar a referência do campo de
entrada/saída com o campo NAME1 da tabela LFA1 do dicionário
ABAP. Clique no botão ‘Sim’ para confirmar.
Como o campo LFA1-NAME1 foi definido para ser um campo somente

de saída, ou seja, só irá apresentar o valor na tela sem as bordas do
campo, então será necessário definir esse atributo ao campo,
clicando na aba ‘Programa’ da janela de atributos para o elemento
que estamos editando. Marque o campo de seleção ‘Só campo de
saída’ para que o campo receba o atributo necessário.
99
Criar Botão – PB_ABRIR_100
Na palheta de elementos, clicar no botão ‘Botão’ e adicionar na área de trabalho, abaixo

dos campos recentemente adicionados conforme a figura 1.5.
Clique no botão para selecioná-lo e na janela de atributos defina:
1. O nome do botão como ‘PB_ABRIR_100’

2. O texto ‘Abrir’ 1
3. O ícone ‘ICON_OPEN’
4. E o código de função ‘FN_ABRIR’ 2
3
O nome do ícone foi obtido na biblioteca de ícones acessando o
botão ao lado do campo ‘Nome ícone’.
Se o texto e o ícone dentro do botão não couberem, é possível

aumentar o tamanho do botão alterando o valor do campo
‘Compr.vis.’ .
Finalização da tela 100
Com todos os elementos necessários para a tela 100 criados, a tela pode ser ativada clicando
no botão ou acionando a tecla de atalho CTRL+F3.
100
Criação dos elementos da tela 100 no ABAP
Os elementos criados na tela 100 precisam ser criados no ABAP para que os valores sejam
copiados do ABAP para a tela e vice-versa.
Os únicos elementos da tela 100 que podem ser criados no ABAP são os campos de
entrada/saída. No nosso caso são os campos LFA1-LIFNR e LFA1-NAME1.
Os elementos de tela a serem criados no ABAP devem ser globais, ou seja, deverão ser criados
no include TOP (ZCADMAT_TOP) e ambos possuem uma característica semelhante, eles são
campos da tabela LFA1. Ou seja, no include TOP iremos criar uma work area com base na
tabela LFA1 através do comando TABLES. Para realizar esse procedimento, siga os passos
abaixo:
1. Abra a include TOP, dando o duplo clique no include ZCADMAT_TOP na árvore de

hierarquia do programa.
2. Insira o comando conforme a figura abaixo.
O comando TABLES cria uma work area com os mesmos componentes da tabela
informada no comando.
3. Ative a include.
Criação do STATUS GUI para a tela 100
Um Status GUI pode ser utilizado por várias telas. No nosso caso, iremos criar um status GUI
exclusivamente para a tela 100 e terá as seguintes propriedades:
Tabela 1.2
Nome STATUS_100
Barra de Ferramentas
Código de
Botões Função
VOLTAR

CANCELAR
101
ABORTAR
Para criar o Status GUI, siga o procedimento abaixo:
 Clique com o botão direito no nome

do programa na árvore hierárquica e
selecione Criar -> STATUS GUI.
 Defina o nome ‘STATUS_100’ no

campo Status;
 Defina o texto breve.
 Marque a opção Status Diálogo
 Clique no botão ‘Avançar’
Será aberto o Status GUI conforme a figura 1.6.

Figura 1.6
Para ativar os botões da barra de ferramentas, abra a seção ‘Teclas de função’, clicando no
ícone e adicione os códigos de função de acordo com a tabela 1.2.
Ative o Status GUI.
102
Criação do TITLE GUI para a tela 100
De forma similar ao Status GUI, um único Title GUI também pode ser utilizado por várias telas.
No nosso exemplo, iremos criar dois Title GUI para a tela 100. O Title GUI será carregado de
acordo com o código de transação utilizado pelo usuário. O programa poderá ser chamado por
duas transações sendo uma para criar/modificar os dados de material para o fornecedor e
outra para visualizar os dados.
Os title GUIs deverão ser criados de acordo com a tabela 1.3.
Tabela 1.3
Title GUI Denominação
TITLE_100_0
1 Criar/Modificar dados de material
TITLE_100_0
2 Visualizar dados de material
Para criar o Title GUI siga os passos abaixo:

selecione Criar -> Títulos GUI.
 Preencha o campo ‘Code

título’ com o nome do Title
GUI definido na tabela 1.3.
 Preencha o campo ‘Título’
com a denominação
definida na tabela 1.3.
 Ative o Title GUI.
Repita o procedimento para o segundo Title GUI.
103
Codificação da Lógica de Processamento da tela 100
A área chamada Lógica de Processamento é a área onde é codificada a lógica de

processamento da tela. Nessa área somente os comandos de tela são aceitos. Os comandos
ABAP não funcionam nessa área.
Para a tela 100, devemos efetuar os seguintes procedimentos para a tela:

 Definir o STATUS-GUI para tela.
 Definir o TITLE-GUI para a tela.
 Validar o campo código do fornecedor (LFA1-LIFNR), ou seja, quando o usuário inserir
um código, o mesmo deverá ser validado pela sua existência no sistema.
 Atribuir o nome do fornecedor no campo LFA1-NAME1, caso o código do mesmo seja
válido.
 Capturar e tratar o código de função utilizado pelo usuário.
Os procedimentos acima não podem ser realizados diretamente pelo processador de tela, pois
não há comandos de tela disponíveis para isso. Para contornar essa limitação, iremos fazer
com que a tela faça as chamadas para o processador ABAP através de módulos. E o ABAP irá
realizar os procedimentos acima.
Como sabemos, a tela é divida em dois eventos principais: PBO (Process Before Output) e PAI
(Process After Input).
O PBO é o responsável pela preparação da tela antes dela ser apresentada para o usuário.
Geralmente, no PBO, é codificada a transferência dos valores a serem apresentados para os
campos da tela, o leiaute da tela e valores padrão.
O PAI é o responsável pelo tratamento dos eventos do usuário, ou seja, quando o usuário clicar
um botão, por exemplo, é no evento PAI que iremos tratar o botão acionado e executar a
rotina necessária.
No nosso caso, podemos dividir os procedimentos para os eventos PBO e PAI:

 PBO
o Definir o STATUS-GUI para tela.
o Definir o TITLE-GUI para a tela.
 PAI
o Validar o campo código do fornecedor (LFA1-LIFNR), ou seja, quando o usuário
inserir um código, o mesmo deverá ser validado pela sua existência no
sistema.
o Atribuir o nome do fornecedor no campo LFA1-NAME1, caso o código do
mesmo seja válido.
o Capturar e tratar o código de função utilizado pelo usuário.
104
Codificação do evento PBO
Abra a tela 100, abrindo a pasta

‘Tela‘ na árvore hierárquica e dando
um duplo clique na tela 100.
Na parte direita da janela, serão abertas as

propriedades das janelas. Clique na aba
‘LógProcmto’, para podermos codificar o
processamento da tela.
Descomente as linhas comentadas, pois

iremos utilizar os módulos definidos pelo
sistema.
Agora vamos codificar o módulo do PBO chamado STATUS_100. No PBO o módulo

STATUS_100 é só uma chamada para o módulo. Teremos que criar o módulo. Para criá-lo, faça
o seguinte:
 Dê um duplo clique no nome do
módulo e na janela de criação do
módulo PBO, selecione a linha
da include O01 (ZCADMAT_O01).
 Clique no botão ‘Avançar’ .
Obs.: Ao dar um duplo clique no

nome do módulo na lógica de
processamento da tela, será solicitada uma confirmação para a criação do módulo.
Favor confirmar.
Todos os módulos PBO a serem criados no programa, serão criados na include O01.
105
O módulo foi criado na include ZCADMAT_O01. Atente que após o nome do módulo, existe o
parâmetro OUTPUT. Isso significa que o módulo é chamado pelo evento PBO.
Agora iremos descomentar as linhas comentadas e atribuir os respectivos nomes do Status GUI
e o Title GUI, para que ambos sejam vinculados à tela, conforme o código abaixo. As
transações tratadas no código abaixo serão criadas posteriormente.
Ative a include ZCADMAT_O01.
106
Codificação do evento PAI
Com a lógica de processamento da tela 100 aberta, será necessário criarmos o módulo
USER_COMMAND_0100. Para isso faça o seguinte:

módulo e na janela de criação do
módulo PBO, selecione a linha da
include I01 (ZCADMAT_I01).
 Ative a include I01.
Obs.: Ao dar um duplo clique no nome do módulo na lógica de processamento da tela,

será solicitada uma confirmação para a criação do módulo. Favor confirmar.
Todos os módulos PAI a serem criados no programa, serão criados na include I01.
O módulo foi criado na include ZCADMAT_I01. Atente que após o nome do módulo, existe o
parâmetro INPUT. Isso significa que o módulo é chamado pelo evento PAI.
O módulo USER_COMMAND_0100 irá conter o código para processar as rotinas referentes aos
códigos de função acionados pelo usuário.
Como sabemos, os códigos de função nada mais são do que um texto atribuído a um elemento
de tela do tipo botão, caixas de seleção, botões de rádio ou elementos do Status GUI tais como
botões, menus e barras de ferramentas. Quando o usuário aciona um desses elementos, o
código de função atribuído a ele é transferido para a variável de sistema SY-UCOMM e para o
campo OK_CODE da tela.
Para evitarmos alterar o campo de sistema SY-UCOMM, iremos definir o campo OK_CODE na
tela e no ABAP para tratarmos o código de função.
Volte para a tela 100 e clique na aba ‘Lista elems’.
107
Essa aba apresenta todos os
elementos adicionados na tela com
seus respectivos atributos. Nós
iremos definir o valor do campo OK
na última linha da tabela com o valor
OK_CODE.
Ative a tela.
Agora é necessário criarmos o objeto correspondente no ABAP. No caso iremos criar uma
variável global na include TOP, conforme se segue:
 Dê um duplo clique no include ZCADMAT_TOP
 Insira o comando marcado na figura abaixo:
 Ative a include.
Com a variável e o campo OK da tela 100 criados, iremos tratar a variável OK_CODE no módulo
USER_COMMAND_0100 do evento PAI.
 Abra a tela 100 na lógica de processamento;

 Dê um duplo clique no módulo USER_COMMAND_100.
 Insira o código para o tratamento da variável OK_CODE , conforme a figura abaixo:
108
 Ative a include.
O comando CALL SCREEN realiza a chamada da tela pretendida. No caso acima,

quando o botão abrir for clicado, o código de função ‘FN_ABRIR’ é copiado
para a variável de sistema SY-UCOMM e para o campo/variável OK_CODE. No
modulo USER_COMMAND_0100, se a variável OK_CODE contiver o valor
‘FN_ABRIR’ a tela 200 será chamada.
Atenção: Os valores literais do Status GUI e TITLE GUI devem ser digitados em maiúsculo. O
sistema diferencia maiúsculo de minúsculo.
O próximo passo será a codificação da validação do campo Fornecedor (LFA1-LIFNR).

A idéia é validarmos o campo Fornecedor quando o usuário teclar ‘Enter’. A validação poderia
ser efetuada no módulo USER_COMMAND_0100 no evento PAI, mas isso acarretaria numa
validação sempre que o módulo PAI fosse acionado, ou seja, qualquer ação tomada na tela
pelo usuário iria ativar a validação do campo Fornecedor.
Uma forma elegante de aplicarmos a validação é utilizarmos no evento PAI uma validação
somente quando o cursor estiver posicionado no campo Fornecedor. Essa validação se dará
em duas etapas: na lógica de processamento e no módulo.
109
Lógica de processamento PAI da tela 100
 Abra a tela 100 na lógica de

processamento
 Insira o código conforme a
marcação na figura ao lado.
 Ative a tela.
O comando FIELD irá fazer com que o módulo especificado seja executado para o campo
informado. Sempre que um determinado campo precisar ser validado, utilize o comando de
tela FIELD informando o nome do campo entrada/saída e o módulo a ser executado.
O parâmetro ON REQUEST significa que a validação só irá ocorrer quando o valor do campo
entrada/saída for modificado, independentemente se algum botão foi acionado. Outra opção
é o parâmetro ON INPUT, que irá validar o campo de entrada/saída independentemente da
modificação do valor do campo.
O próximo passo é a codificação do módulo VALIDA_LIFNR_100.
Módulo VALIDA_LIFNR_100
Será necessária a criação do módulo VALIDA_LIFNR_100, o qual está sendo chamado no

evento PAI para o campo LFA1-LIFNR.
 Dê um duplo clique no nome do módulo VALIDA_LIFNR_100;

 Será solicitada a confirmação da criação do módulo. Confirme.
 Selecione a include I01
(ZCADMAT_I01) para que o módulo
seja criado dentro dela.
 Ative o include I01.
Dentro do módulo será inserido o código para a validação do campo Fornecedor.
Dentro do módulo terá uma chamada para uma sub-rotina ou Form. É aconselhável inserir o
código ABAP dentro de sub-rotinas quando houver a necessidade de criação de objetos ABAPs,
tais como variáveis, work areas ou tabelas internas, pois se criarmos um objeto dentro do
110
módulo, esse objeto será um objeto pseudo global. Ver a explicação na seção Melhores
Práticas, no final desse documento.
 Dê um duplo clique no nome do FORM (VALIDA_LIFNR_100) para que o mesmo seja

criado.
 Será solicitado a confirmação da
criação da sub-rotina. Confirme.
 Selecione a linha da include F01
 Salve a include F01.
Obs.: Todos as sub-rotinas a serem

criadas no programa, serão criados na include F01.
111
Dentro do form VALIDA_LIFNR_100 insira o código conforme figura abaixo e ative as includes
F01 e I01.
O select irá selecionar todos os campos da tabela transparente de mestre de fornecedor LFA1
e irá atribuir os valores para os campos correspondentes da work area LFA1. Um desses
campos é o nome do fornecedor que está atribuído na tela 100 (LFA1-NAME1), ou seja, caso a
validação seja executada com sucesso, o nome do fornecedor será apresentado na tela.
O comando MESSAGE com o tipo de mensagem de erro ‘E’ apresentado no código acima, faz
com que todos os campos da tela sejam fechados com exceção do campo validado. Isso faz
com que o usuário encontre rapidamente qual é o campo problemático e corrija o valor. Os
outros campos, caso houver, só serão liberados para edição quando o usuário inserir um valor
112
válido. Em um programa do tipo Report, o comando MESSAGE com tipo de mensagem de erro,
faz com que o programa seja finalizado.
Criação das transações
Os programas de module pool, diferentemente de um programa do tipo Report, não são

executáveis, ou seja, não é possível executá-lo diretamente pelo editor ABAP.
Os programas do tipo module pool só podem ser executados através de uma transação. No
nosso exemplo, criaremos duas transações conforme a tabela 1.4.
Tabela 1.4
Transaçã
o Denominação
ZMAT02 Criar/Modificar dados de material
ZMAT03 Visualizar dados de material
Segue abaixo o procedimento para criar as transações:
 Clique com o botão direito no nome do

programa na árvore hierárquica e
selecione a opção Criar -> Transação.
 Preencher o campo ‘Código de Transação’

com o valor ZMAT02.
 Preencher o campo ‘Texto breve’ com a
denominação da transação.
 Selecionar a opção ‘Programa e tela
(transação de diálogo)’
Obs.: Como o programa é um module
pool, a opção a ser selecionada é
‘Programa e tela (transação de diálogo)’.
113
Na próxima tela, preecher os seguintes campos:
 Preencha o campo ‘Programa’ com o nome

do programa (ZCADMAT).
 Informe o número da tela que deverá ser
carregada quando o programa for carregado
(100).
 Selecione a opção ‘Transação Professional
User’.
 E marque todas as capacidades GUI: SAPGUI
para HTML, Java e Windows.
 Salve a transação e atribua ao pacote e
à change request.
Repita o mesmo procedimento para criar a transação ZMAT03.
114
A tela 200 é a tela que contém dados do fornecedor. Esses dados serão divididos entre duas
abas, de forma a organizar os campos na tela. Além disso, haverá o botão material para abrir
uma janela do tipo pop-up para apresentar os dados de materiais.
A tela 200 possui o seguinte leiaute:
A criação da tela 200 seguirá a seguinte seqüência:

 Criação da tela 200
 Definição do Status GUI
o Criação do Status GUI
o Associação do Status GUI com a tela
 Definição do Title GUI

o Criação do Title GUI
o Associação do Title GUI com a tela
 Criação dos campos de entrada/saída

 Criação dos botões
 Criação do Controle de Fichas
o Criação do elemento Controle de ficha na tela
o Declaração do Controle de Ficha no ABAP
o Chamada das subtelas do controle de ficha na lógica de processamento nos
eventos PBO e PAI
115
 Para criar uma nova tela, clique com o
botão direito no nome do programa e
na janela de pop-up que é
apresentado, selecione a opção Criar -
> Tela.
 Insira o número da tela (0200) e

clique no botão ‘Avançar’
ou tecle Enter.
 Obs.: O valor pode ser de ‘0001’
a ‘9999’.
 Na aba ‘Características’,
preencha o campo
‘Descrição breve’ e defina o
tipo de tela como ‘Normal’
e salve a tela .
116
 Clique na aba ‘Lista elemens.’ e insira
nome da variável OK_CODE no
campo OK da tela 200. Lembre-se
que a variável informada ‘OK_CODE’
irá receber o código de função do
objeto acionado pelo usuário, um
botão por exemplo e ele será tratado
no evento PAI para executar uma
determinada rotina.
117
Definição do Status GUI
Criação do Status GUI
Realizar o mesmo procedimento para a criação do Status GUI da tela 100 utilizando os dados
da tabela 2.1.
Tabela 2.1
STATUS GUI
Nome Texto breve
STATUS_20
0 Status GUI tela 200
Barra de Ferramentas
Botões Código de Função
SALVAR
VOLTAR
CANCELAR
ABORTAR
Para criar o Status GUI, siga o procedimento abaixo:


campo Status;
 Marque a opção Status Diálogo.
118
Para ativar os botões da barra de ferramentas, abra a seção ‘Teclas de função’, clicando no
ícone e adicione os códigos de função de acordo com a tabela 2.1.
Salve o Status GUI.
Barra de botões
O próximo passo é criar o botão na barra de botões para o material. A criação do botão se dará
no próprio Status GUI que acabamos de criar, mas na seção ‘Barra de botões’. Abra a sessão
‘Barra de botões’ clicando no ícone .
Os dados para criar o botão é:

Tabela 2.2
Barra de Botões
Cód. Função &Material
Texto Material
Ícone ICON_MATERIAL
Txt.
Informação Materiais do fornecedor
Tecla de Atalho Shift-F7
Texto de Ícone Material
Siga o procedimento para a criação do botão na barra de botões:
 Insira o código de função informado na

tabela 2.2 como primeiro botão e tecle
Enter.
 Selecione a opção ‘Texto estático’.

119
 Preencha os campos ‘Texto da Função’,
‘Nome do Ícone’ e ‘Texto de informação’
de acordo com a tabela 2.2.
 Atribua a tecla de atalho para o código de função de acordo

com tabela 2.2.
O botão foi criado, mas ele não possui um texto próximo

ao ícone.
 Para inserir um texto de ícone dê um duplo clique
no código de função criado e preencha o campo
‘Texto de ícone’ conforme a tabela 2.2.
Barra de Menu
A barra de menu irá conter um menu para consulta onde será possível consultar os dados do
fornecedor acessando a transação standard XK03 e também terá um código de função para
chamar a tela de materiais do fornecedor, o qual será o mesmo código de função da barra de
botões.
Segue abaixo o procedimento para a criação da barra de menu:
 Abra a sessão ‘Barra de menu’ clicando no ícone .

 A seção é expandida e assim é possível visualizar as áreas onde serão criados os
menus. As áreas em branco são onde serão criados os menus, conforme a imagem
abaixo.
 Na primeira área, digite o valor ‘Fornecedor’ e dê um duplo clique, isso fará com que
uma área de códigos de função seja criado.
120
A coluna ‘Cód.’ é a área onde será inserido o código de função e a
coluna ‘Texto’ é a área onde será inserido um breve texto descritivo do
código de função. No nosso exemplo, iremos criar um submenu
chamado ‘Consulta’. Quando nos referimos a submenus, não podemos
especificar o código de função, mas somente o texto.
 Para criar o submenu, insira o valor

‘Consulta’ na primeira linha da coluna
‘Texto’ e tecle ‘Enter’.
 Será apresentado o sinal de maior que (>) ao
lado do texto, indicando que esse menu
também possui códigos de função. Dê um duplo clique no texto ‘Consulta’ que o irá
abrir o submenu.
 Insira o código de função ‘&FORN’ e o texto ‘Mestre de Fornecedor’ na primeira linha,
conforme a imagem abaixo:
O resultado será o da imagem apresentada abaixo:
O próximo item a ser adicionado ao menu é o código de função do material, o mesmo do

botão da barra de menu. Iremos adicionar logo abaixo do menu Consulta.
 Adicione o código de função

‘&MATERIAL’ na primeira coluna logo
abaixo da linha de consulta e o texto
‘Material’ ao lado.
O resultado final do Status GUI será:
Ative o Status GUI
121
Definição do Title GUI
Na tela 200, será utilizado os Titles GUI da tela 100, seguindo a mesma lógica de condicionar a
associação do Title GUI pela transação.
Associação do Status GUI e Title GUI na tela 200
Após a criação do Status GUI e Title GUI, os mesmos deverão ser associados na tela 200
quando o evento PBO for acionado.
Para carregar o Status GUI e Title GUI na tela, é necessário realizar o mesmo procedimento
executado na tela 100, ou seja, o módulo STATUS_0200 no evento PBO deverá ser criado na
include O01 (ZCADMAT_O01) e utilizar os comandos SET PF-STATUS e SET TITLEBAR. Segue
abaixo o código do módulo STATUS_0200:
Os Title GUI utilizados na tela 100 também serão utilizados na tela 200.
Atenção: Os valores literais do Status GUI e TITLE GUI devem ser digitados em maiúsculo. O
sistema diferencia maiúsculo de minúsculo.
122
Tratamento dos códigos de função no evento PAI – Tela 200
Os códigos de função presentes no Status GUI e na tela através de botões e barra de menus
deverão ser tratados no módulo USER_COMMAND_0200 do evento PAI. De forma similar ao
procedimento efetuado na tela 100, o módulo USER_COMMAND_0200 deverá ser criado na
include I01 (ZCADMAT_I01) e dentro dele ser codificado o tratamento dos códigos de função.
Segue abaixo o código do módulo USER_COMMAND_0200:
No momento somente os códigos de função ‘VOLTAR’, ‘CANCELAR’ e ‘ABORTAR’ da barra de

ferramentas serão tratados. Os outros códigos de função serão tratados posteriormente, de
acordo com o contexto.
123
Adicionando elementos na tela 200
Para adicionar os elementos na tela 200, clique no botão ‘Layout’ para abrir o
Screen Painter.
Os elementos que serão inseridos na tela 200 deverão ter a seguinte disposição:
A tela possuirá um campo texto (Título ‘Fornecedor’), dois campos de entrada/saída (Código
do fornecedor e nome), um controle de fichas com dois botões (abas) e duas áreas de subtelas
e um botão.
Os campos que farão parte de cada aba, não fazem parte da tela 200, mas sim de duas
subtelas que serão criadas e associadas ao controle de fichas posteriormente.
124
Campos de entrada/saída e Campo texto
Primeiro, crie os campos de texto e entrada/saída de forma similar ao da tela 100, com
exceção do campo LFA1-LIFNR, o qual não será editável, conforme a tabela 2.1.
Tabela 2.1
ID Elemento Nome Texto Campo de Só Código de Ícone
entrada Campo Função
de saída
1 Campo Texto LFA1-LIFNR Fornecedor
2 Campo Entrada/Saída LFA1-LIFNR Não
3 Campo Entrada/Saída LFA1-NAME1 Não Sim
Figura 2.1
1 2 3
Obs.: Os campos podem ser copiados da tela 100 e colados e adaptados na tela 200.
Controle de Fichas
O controle de fichas será utilizado para separar os dados do fornecedor em abas. A primeira
aba a ser criada será Endereço, a qual conterá os campos de endereço do fornecedor. A
segunda aba conterá os dados de controle.
Quando o controle de fichas é apresentado ao usuário, os campos que fazem parte de uma
determinada aba não estão incluídos nas abas, como se parece. Os campos fazem parte de
uma subtela a qual é associada à aba. Sendo assim, no momento de criar o controle de fichas
na tela 200, será adicionado um elemento chamado ‘Área de Subtela’ e na lógica de
processamento iremos associar a área de subtela com a subtela.
125
O controle de ficha a ser criado, deverá ter as propriedades de acordo com a tabela 2.2:
Tabela 2.2
Botão Nome Texto Código de Campo de Área de
(Aba) Função Referência Subtela
Endereç
Endereço PB_END o FN_END SCR_END SCR_END
PB_CONTROL FN_CONTROL SCR_CONTROL SCR_CONTROL
Controle E Controle E E E
O processo de criação do controle se dá da seguinte forma:
 Clique no botão ‘Controle de Fichas’ na paleta de elementos

 Insira o controle de fichas na área de trabalho abaixo dos campos do fornecedor
O controle de fichas possui os seguintes componentes:

1. Botões: os botões são as abas do controle de fichas. Se for necessário
adicionar uma nova aba, adicione um novo botão
2. Área de subtela: É a área que irá receber o elemento ‘Área de Subtela’
 Clique na área vermelha ao lado da aba,

para selecionar o controle de ficha, e dê o
nome ‘CT_FORN’ para o controle de ficha.
126
 Clique na aba ‘Tab1’ e altere os seguintes dados na janela de
atributos
o Preencha o campo ‘Nome’ com o valor ‘PB_END’;
o Preecha o campo ‘Texto’ com o valor ‘Endereço’;
o Preencha o campo ‘Código de função’ com o valor
‘FN_END’;
o Preencha o campo ‘Cpo.ref.’ com o valor ‘SCR_END’.
o Clique no botão ‘Área de subtela’ na palheta de elementos e adicione na

área de subtela do controle de Ficha.
Depois de inserir a área de subtela no controle de fichas, clique na área

de subtela e veja que o nome da subtela é exatamente igual ao campo
de referência definido no botão (aba).
Para a aba controle, repita o procedimento acima utilizando os dados informados na tabela
2.2.
127
Botão
Abaixo do controle de ficha, será adicionado um botão chamado Material, que ao ser clicado
deverá abrir a tela de materiais do fornecedor. O botão deverá ter os mesmos atributos do
botão da barra de ferramenta e da entrada ‘Material’ da barra de menu, conforme a tabela
2.3.
Tabela 2.3
Botão Material
Nome PB_MATERIAL
Cód. Função &MATERIAL
Texto Material
Ícone ICON_MATERIAL
InfoRápida Materiais do fornecedor
O procedimento para a criação do botão é:
 Clique no botão na palheta de

elementos e adicione na área de
trabalho abaixo do controle de
fichas.
 Clique no botão para que o mesmo seja selecionado e

na janela de atributos, defina os atributos do botão de
acordo com a tabela 2.3.
 Altere o valor do campo ‘Compr.vis.’ para ajustar a
largura do botão.
 Ative a tela.
O processo de criação da tela está finalizado. O próximo passo é criar os objetos ABAP
correspondentes aos elementos da tela e codificar a lógica de processamento da tela 200.
128
Criar os objetos correspondentes aos elementos da tela no ABAP
Os elementos que são adicionados na tela também devem ser criados no ABAP para que
possam ser controlados via programação. O controle de fichas também deverá ser criado no
ABAP. Os componentes do controle de fichas como o botão e a área de subtela, não existem
correspondentes no ABAP.
A criação do controle de fichas no ABAP deverá ser realizada na include TOP, conforme
procedimento abaixo:
 Entre na include ZCADMAT_TOP em modo de edição
 Insira o código de declaração do controle de ficha como a imagem abaixo marcada.
A declaração do controle de fichas no ABAP e o nome do controle de fichas na tela

devem possuir o mesmo nome, para que os objetos da tela e do ABAP possam trocar
dados e influir diretamente no comportamento do objeto na tela.
Codificação do Controle de Fichas na lógica de processamento e no

ABAP
Como mencionado anteriormente, os campos que são apresentados dentro de uma aba não
fazem parte da área dentro da aba diretamente, mas sim indiretamente, através de uma
subtela. No nosso exemplo, foram criadas duas abas e duas áreas de subtela, sendo uma para
cada aba.
O processo agora é associar a área de subtela presente dentro do controle de fichas com uma
subtela. Quando o usuário clicar na aba ‘Endereço’, a subtela 210, por exemplo, será anexada à
área de subtela SCR_END. E quando o usuário clicar na aba ‘Controle’, a subtela 220, por
129
exemplo, será anexada à área de subtela SCR_CONTROLE. Esse processo de associação de
subtela com área de subtelas é realizado no evento PBO da tela 200, na lógica de
processamento. Segue abaixo o código da associação da subtela com a área de subtela:
No evento PBO, a área de subtela SCR_END está incluindo a tela ‘0210’ do programa contido
na variável de sistema SY-REPID, que no nosso caso é o nome do nosso programa ZCADMAT. E
a área de subtela SCR_CONTROLE está incluindo a tela ‘0220’ do programa contido na variável
de sistema SY-REPID.
No evento PAI, o número de tela associado à área de subtela está implícita.
O código acima está anexando duas subtelas na tela 200, ou seja, as telas 210 e 220 são
subtelas ou telas filhas da tela principal, que é a tela 200. Até o momento, as telas 210 e 220
não foram criadas. Elas serão criadas posteriormente, de acordo com o contexto do tutorial.
O fluxo de processamento das telas 200 e as subtelas 210 e 220 possuem a seguinte lógica:
Quando a tela é carregada, o primeiro evento a ser executado é o PBO. Logo, os comandos são
executados seqüencialmente. No caso da tela 200, o módulo STATUS_0200 é executado
primeiro e depois a subtela 210 será chamada e o evento PBO da 210 será executada. Se
houver algum módulo ou comando de tela na 210, eles serão executados seqüencialmente. Ao
término do evento PBO da tela 210, o sistema retornará para a tela 200 e irá chamar a tela 220
e executar o evento PBO e seus respectivos comandos e chamadas de módulos. Ao término do
evento PBO da tela 220, a sistema retorna para a tela 200 e finaliza o evento PBO,
apresentando a tela para o usuário.
Quando o usuário acionar algum evento, por exemplo, teclar ‘Enter’, o sistema irá disparar o
evento PAI da tela 200. Os comandos de tela e chamadas de módulos serão executados
seqüencialmente, sendo que no nosso exemplo, o módulo USER_COMMAND_0200 será
executado e após o mesmo, a subtela 210 será chamada e o evento PAI disparado. Ao término
do evento PAI da tela 210 o sistema retorna para a tela 200 no evento PAI e chama a tela 220 e
o evento PAI disparado. Ao término da execução do evento PAI da tela 220, o sistema retorna
para a tela 200 e finaliza o evento PAI. Se o campo ‘Tela Seguinte’ na aba ‘Características’ da
130
tela 200 estiver com o número 200, o sistema dispara o evento PBO da tela 200, novamente.
Ou seja, teremos um evento cíclico.
Tela 210
PBO
Início do evento
...
Fim do evento
1 PAI
Início do evento
Tela 200 ...
Fim do evento
PBO 3
CALL SUBSCREEN scr_end INCLUDING sy-repid ‘0210’.
CALL SUBSCREEN scr1_controle INCLUDING sy-repid ‘0220’.
5
Tela 220
PAI
CALL SUBSCREEN scr_end 2 PBO
CALL SUBSCREEN scr_controle.
Início do evento
...
Fim do evento
PAI
4 Início do evento
...
Fim do evento
131
Ativar a aba selecionada no controle de fichas
Para que a aba selecionada pelo usuário torne-se ativa, é necessário informar o controle de
fichas de forma explícita qual a aba o usuário selecionou. Para isso, utilizaremos o controle
CT_FORN no ABAP para passar o código de função correspondente à aba selecionada para o
usuário. O controle CT_FORN possui um componente chamado ACTIVETAB e atribuiremos a
ele o código de função da aba selecionada. Por se tratar de uma ação do usuário, o código
deverá inserido no evento PAI no módulo USER_COMMAND_0200, como mostrado na área
marcada abaixo:
A variável OK_CODE contém o código de função do botão (aba) selecionada pelo usuário, logo
o componente ACTIVETAB do controle de ficha irá receber o código de função, e quando o
evento PBO da tela 200 for disparado, a aba selecionada pelo usuário ficará ativa.
132
Criação das subtelas do Controle de Ficha
O controle de ficha que foi criado anteriormente possui duas abas (botões) e para cada aba foi
criada um área de subtela, a qual está associada a duas subtelas ‘0210’ e ‘0220’. Essas duas
subtelas serão criadas para inserir os campos relacionados as abas endereço e controle.
Diferentemente das telas normais, as subtelas não possuem Status GUI, Title GUI e nem o
campo OK_CODE, pois os três objetos são herdados da tela principal na qual as subtelas fazem
parte.
Criação da subtela 210

botão direito no nome do programa e na
janela de pop-up que é apresentado,
selecione a opção Criar -> Tela.
 Insira o número da tela (210) e clique no

botão ‘Avançar’ ou tecle Enter.
 Obs.: O valor pode ser de ‘0001’ a ‘9999’.
preencha o campo ‘Descrição
breve’
 Defina o tipo de tela como
‘Subtela’
 Salve a tela .
133
O campo OK_CODE está fechado. Essa é uma das características das subtelas.
Adicionando elementos na subtela 210
Os elementos serão inseridos na subtela através do Screen Painter.

Tabela 3.1
ID Elemento Nome Texto Campo de
entrada
1 Campo Texto LFA1-STRAS Rua
2 Campo Texto LFA1-ORT01 Cidade
3 Campo Texto LFA1-ORT02 Bairro
4 Campo Texto LFA1-REGIO Estado
5 Campo Texto LFA1-LAND1 País
6 Campo entrada/saída LFA1-STRAS Não
7 Campo entrada/saída LFA1-ORT01 Não
8 Campo entrada/saída LFA1-ORT02 Não
9 Campo entrada/saída LFA1-REGIO Não
1
0 Campo entrada/saída LFA1-LAND1 Não
Figura 3.1
1 6
2 7
3 8
4 9
5 10
134
Criação da subtela 220

 Insira o número da tela (220) e clique no

botão ‘Avançar’ ou tecle Enter.
 Obs.: O valor pode ser de ‘0001’ a ‘9999’.
 Na aba ‘Características’, preencha o

campo ‘Descrição breve’
‘Subtela’
 Salve a tela .
135
O campo OK_CODE está fechado. Essa é uma das características das subtelas.
Adicionando elementos na subtela 220
Os elementos serão inseridos na subtela através do Screen Painter.

Tabela 3.2
ID Elemento Nome Texto Campo de
entrada
1 Campo Texto LFA1-STCD1 CNPJ
2 Campo Texto LFA1-STCD3 IE
3 Campo Texto LFA1-STCD4 Nº ID fiscal 4
4 Campo Texto LFA1-TXJCD Domicílio fiscal
5 Campo entrada/saída LFA1-STCD1 Não
7 Campo de seleção LFA1-STKZU Sujeito a IVA Não
9 Campo entrada/saída LFA1-TXJCD Não
10 Campo Texto LFA1-WERKR Relev.nív.centro
11 Botão de Rádio SCR_220-WERKR_S Sim Não
12 Botão de Rádio SCR_220-WERKR_N Não Não
Figura 3.2
1 5
2 6 7
3 8 10 11 12
4 9
O campo de seleção não precisa de um campo texto para ele, pois o atributo texto pode ser
utilizado para atribuir um título.
136
Os nomes dos botões de rádio não estão incluídos na work area LFA1, mas sim na work area
SCR_220, que será criada no ABAP. O texto dos botões de rádio segue a mesma lógica do
campo de seleção, ou seja, é só preencher o atributo texto do campo.
Atenção: Os botões de rádio devem ser agrupados para que somente uma das opções sejam
selecionadas. Para agrupar os campos, siga os procedimentos abaixo:
 Marque os dois campos, para que ambos

possam ser agrupados.
 Clique com o botão direito na área

selecionada e escolha a opção ‘Grupo de
botões de rádio’ -> ‘Definir’, no menu pop-
up.
Obs.: Se os botões de rádio não forem agrupados, todos os botões ficarão

selecionados e não terá funcionalidade.
Criação dos elementos das subtelas no ABAP
Os campos de entrada/saída e campo de seleção das subtelas 210 e 220 estão todas
associadas com a work area LFA1, sendo que a mesma já foi criada na include TOP
(ZCADMAT_TOP) para a tela 100 e 200 e pode ser utilizada pelas subtelas.
Os botões de rádio da subtela 2 são um caso a parte, pois são dois objetos que irão depender
do valor de um único campo, no caso o campo LFA1-STKZU. Logo, foi associado um
componente da work area SCR_220 para cada um dos botões de rádio.
Agora teremos que criar a work área no ABAP, para que o campo da tela seja reconhecido pelo
ABAP e vice-versa. Para isso, deve-se entrar na include TOP (ZCADMAT_TOP) e criar um tipo de
dados e uma work area com o tipo de dados recém criado.
137
Segue abaixo o código da include TOP:
Após a criação da work area, será necessário fazer o tratamento para que o botão de rádio
reflita o valor presente no campo LFA1-WERKR. A work area será tratada no evento PAI da tela
100 na validação do campo LFA1-LIFNR, pois é lá que está sendo carregado os dados do
fornecedor na tabela LFA1. A codificação poderia ser realizada na tela 200 no evento PBO ou
na subtela 220, também no evento PBO.
Segue abaixo o código do tratamento dos botões de rádio da tela 220 no FORM
VALIDA_LIFNR_100, que é chamado dentro do módulo VALIDA_LIFNR_100.
138
A tela 300 é uma tela do tipo pop-up e irá possuir uma table-control com os dados de material
do fornecedor informado. O Status GUI a ser criado para a tela de pop-up tem um tipo
diferente dos Status GUI utilizado até então.
Segue abaixo o procedimento para a criação da tela:

 Insira o número da tela (300) e clique

no botão ‘Avançar’ ou tecle
Enter.
 Obs.: O valor pode ser de ‘0001’ a
‘9999’.
preencha o campo ‘Descrição
breve’
‘Subtela’
 Salve a tela .
139
140
As telas de pop-up possuem o campo OK_CODE aberto, logo iremos definir a variável no
campo OK_CODE da tela.
Definição do Status GUI
O Status GUI da tela 300 será do tipo diferente dos Status GUIs criados até o momento. O tipo
de Status GUI a ser criado é ‘Caixa de Diálogo’ e a característica desse tipo é que a barra de
menu e a barra de ferramentas não existem.
Para criar o Status GUI, siga o procedimento

abaixo:

campo Status;
 Marque a opção ‘Caixa de
Diálogo’.
141
Criação dos Códigos de Função na barra de botões
Os códigos de função na barra de botões serão criadas de acordo com a tabela 3.1.
Tabela 3.1
STATUS GUI
Nome Texto breve
STATUS_300 Status GUI tela 300
Barra de Botões
Código de Função Texto de Função ícone Txt de Informação
OK Ok ICON_OKAY Continuar
CANCELAR Cancelar ICON_CANCEL Cancelar alteração
Criação do botão OK
 Abra a sessão ‘Barra de botões’.

 Insira o código de função OK no
primeiro campo.
 Tecle ‘Enter’ que abrirá uma janela.
 Selecione a opção ‘Texto estático’.

 Preencha os seguintes campos de

acordo com a tabela 3.1.
o Texto de função
o Nome do Ícone
o Texto de Informação
142
 Atribua a tecla de atalho ‘F8’ para o botão
O botão ‘OK’ está pronto. Faça o mesmo procedimento para o botão cancelar utilizando os
dados da tabela 3.1.
Criação do TITLE GUI para a tela 300
A tela 300 irá chamar uma única TITLE GUI e deverá ser criados de acordo com a tabela 3.2.
Tabela 1.3
Title GUI Denominação
TITLE_300 Tabela de materiais
Para criar o Title GUI siga os passos abaixo:

selecione Criar -> Títulos GUI.
 Preencha o campo ‘Code

título’ com o nome do Title
GUI definido na tabela 1.3.
 Preencha o campo ‘Título’
com a denominação
definida na tabela 1.3.
 Ative o Title GUI.
143
Associação do Status GUI e Title GUI na tela 300
Após a criação do Status GUI e Title GUI, os mesmos deverão ser associados na tela 300
quando o evento PBO for acionado.
Para carregar o Status GUI e Title GUI na tela, é necessário realizar o mesmo procedimento
executado na tela 100, ou seja, o módulo STATUS_0300 no evento PBO deverá ser criado na
include O01 (ZCADMAT_O01) e utilizar os comandos SET PF-STATUS e SET TITLEBAR. Segue
abaixo o código do módulo STATUS_0300:
Tratamento dos códigos de função no evento PAI – Tela 300
Os códigos de função presentes no Status GUI deverão ser tratados no módulo

USER_COMMAND_0300 do evento PAI. De forma similar ao procedimento efetuado na tela
100, o módulo USER_COMMAND_0300 deverá ser criado na include I01 (ZCADMAT_I01) e
dentro dele ser codificado o tratamento dos códigos de função.
Segue abaixo o código do módulo USER_COMMAND_0300:
144
No momento somente os códigos de função ‘OK’ e ‘CANCELAR’ irão fechar a tela 300 e voltar
para a tela 200. Eles serão incrementados de acordo com o contexto.
TABLE CONTROL de materiais
O table control é um recurso para inserir uma tabela contendo valores na tela. Ele é composto
de colunas que são os campos de entrada/saída e títulos de colunas que são os campos textos
ou campos de entrada/saída. As colunas podem conter também botões de rádio, campos de
seleção e botões. Todos os objetos mencionados com exceção dos botões, devem ter objetos
no ABAP com o mesmo nome dos elementos da tela.
Obs.: A partir do momento que o table control for criado, a tela só poderá ser ativada quando
a lógica de processamento estiver codificada e os objetos ABAP criados, caso contrário, o
sistema irá apontar erro na ativação.
A table control terá o seguinte leiaute:
Preparação para a criação do Table Control
Antes de criar o Table Control, é necessário prepararmos a tabela interna no ABAP que irá ser
associada ao Table Control. A tabela interna terá os mesmos componentes da tabela
transparente ZMATERIAL e será criada na include TOP (ZCADMAT_TOP), pois deve ser global.
Além de possuir os componentes da tabela transparente ZMATERIAL, também será adicionado
o componente MAKTX (descrição do material) e o componente SEL, que será utilizado receber
um marcador indicando qual registro foi selecionado pelo usuário no table control. A tabela
interna irá ser chamada de TI_MATERIAL e terá cabeçalho (header line).
Segue abaixo a criação da tabela interna:
145
Após a declaração da tabela interna TI_MATERIAL, ative a include TOP.
Criação da table control
A criação da table control é realizada no Screen Painter. Siga os procedimentos abaixo para a
criação do table control.
Clique no botão Layout na barra de botões para abrir o Screen Painter.
 Clique no botão Table Control na palheta de elementos

 Adicione o Table Control na área de trabalho
 Clique no Table Control e na janela de atributos insira o

nome ‘TC_MATERIAL’ e tecle ‘Enter’.
 Marque as opções de linhas de separação Vertical e

Horinzontal para as colunas.
Como os elementos da tela devem possuir um objeto correspondente no ABAP, com a table
control é a mesma coisa. Além de a table control ter o objeto criado através do comando
CONTROL no ABAP, as colunas da table control também deverão ser criados no ABAP. No
nosso caso, iremos associar as colunas da table control com os campos de uma tabela interna,
na qual será a tabela interna TI_MATERIAL , a qual foi criada anteriormente na include TOP.
146
Para adicionar as colunas na Table Control, será necessário adicionar os campos de
entrada/saída na table control. Utilize a tabela 3.4 para definir as propriedades das colunas.
Tabela 3.4
Nome Texto Campo Tipo Comprimento
Entrada Def/Vis
TI_MATERIAL-MATNR Material X CHAR 18/18
TI_MATERIAL-MAKTX Denominação CHAR 40/25
TI_MATERIAL-MTART TpMat X CHAR 4/4
TI_MATERIAL-MBRSH SI X CHAR 1/2
TI_MATERIAL-MEINS UMB X CHAR 3/3
TI_MATERIAL-BRGEW Peso Bruto X DEC 17/17
TI_MATERIAL-NTGEW Peso Líquido X DEC 17/17
 Clique no botão de campo de

entrada/saída e adicione no
Table Control
 Após adicionar o campo,
redimensione a coluna para o
tamanho desejado
 Com a coluna selecionada, abra a
janela de atributos e insira o
nome ‘TI_MATERIAL-MATNR’. O
nome da coluna será o nome da tabela interna e o
componente.
 Na janela de atributos, defina as propriedades da coluna de acordo com a tabela 3.4:
Repita a operação para os outros campos e defina os atributos das colunas de acordo
com a tabela 3.4.
147
Após a criação das colunas da table control, será necessário inserir os títulos de coluna.
Para inserir o título de coluna, é necessário verificar se o

atributo ‘C/tít.col’ da table control na janela de atributos
está ativado.
Ao ativar o título de coluna, a área título de coluna é apresentada na table control,

conforme a figura abaixo:
Área de título de
coluna
Para inserir o título de coluna em cada coluna, é necessário inserir um campo de texto
na coluna desejada. Siga o procedimento abaixo para realizar a operação. Utilize os
dados da tabela 3.5 para definir os atributos do campo texto.
Tabela 3.5
Significado Nome Texto
Material TI_MATERIAL-MATNR Material
Descrição do material TI_MATERIAL-MAKTX Descrição
Tipo de Material TI_MATERIAL-MTART TpMat
Setor Industrial TI_MATERIAL-MBRSH SI
Unidade de medida básica TI_MATERIAL-MEINS UMB
Peso Bruto TI_MATERIAL-BRGEW Peso Bruto
Peso Líquido TI_MATERIAL-NTGEW Peso Líquido
 Seleciona o botão de texto na palheta de elementos .

 Insira o campo texto na primeira coluna da table control

Clique no campo texto recém adicionado e
define os seguintes atributos na janela de
atributos:
o Nome: TI_MATERIAL-MATNR
o Texto: Material
148
Obs1.: Não é necessário definir o comprimento do título de coluna, pois o
comprimento é definido automaticamente, de acordo com o tamanho da
coluna em si.
Obs2.: O nome do campo texto pode ser o mesmo do campo de entrada/saída
que define a coluna.
O resultado final no Screen Painter, deverá ser semelhante à figura abaixo, sendo que
a coluna TI_MATERIAL-MAKTX, é a única que deverá ficar fechada.
Para finalizar a definição da table control na tela, será necessário definir a coluna de
marcação de linha, conforme apresentado na figura abaixo:
A coluna de marcador de linha tem como funcionalidade permitir que o usuário

selecione um ou mais registros da table control, dependendo da configuração.
149
Para definir a coluna de marcação de linha, é necessário seguir os passos abaixo no
Screen Painter:
 Selecione a table control.

 Na janela de atributos, defina se a marcação de linha
será simples ou múltiplo.
 Marque o checkbox ‘C/col.marc’ e informe o

nome do campo da tabela interna que irá
receber o valor de marcação do registro. O
nome do campo deverá ser a tabela interna e o nome do campo. No nosso
caso, o valor a ser inserido é TI_MATERIAL-SEL.
Quando o usuário uma linha ou mais linhas, o componente definido no campo de

coluna de marcação, irá inserir o valor ‘X’ no registro correspondente na tabela
interna. Com isso, será possível saber no ABAP qual registro da table control que foi
selecionado pelo usuário.
150
Declaração da table control no ABAP (Include TOP)
Após a criação da table control na tela 300, será necessária a declaração da table control no
ABAP. Para isso, o comando CONTROL será utilizando mais uma vez na include TOP
(ZCADMAT_TOP), conforme a figura abaixo:
Na declaração, o controle TC_MATERIAL está associado à tela 300.
Codificação da lógica de processamento da tela 300
Para podermos ativar a tela 300, falta definirmos o código na lógica de processamento da tela
nos eventos PBO e PAI, conforme o procedimento abaixo:
 Abra a tela 300 e insira o comando LOOP nos eventos PBO e PAI conforme a figura
abaixo:
Os comandos LOOP nos eventos PBO e PAI irão executar o laço nos registros da table
control e não da tabela interna, pois o código será processado pelo processador da
tela e não pelo processador ABAP. Se a table control apresenta 10 registros na tela, o
LOOP irá executar 10 laços.
Dentro dos LOOPs dos eventos PBO e PAI, será necessário incluir os módulos para
transferir os dados da table control para a tabela interna e vice-versa.
151
No evento PBO, os dados da tabela interna deverão ser transferidos para a table
control. Sendo assim, será criado o módulo TRANSF_DADOS_TI_PARA_TC_300,
conforme o procedimento abaixo:
 Insira o módulo TRANSF_DADOS_TI_PARA_TC_300 dentro do LOOP da TI_MATERIAL.

módulo e selecione a opção ‘Sim’
para confirmar a criação do
módulo:
 Seleciona a include O01

 Dentro do módulo TRANSF_DADOS_TI_PARA_TC_300, insira o código conforme a

figura abaixo:
152
A lógica do evento PBO para a table control é a seguinte:
o Para cada registro lido da table control:
 O registro correspondente na tabela interna será transferido para a
table control .
 A quantidade de registros total será atribuída ao componente LINES
do controle TC_MATERIAL.
 Caso não haja o registro correspondente na tabela interna, o laço na
table control é finalizado.
Criação dos botões de funcionalidades da Table Control
Os botões de funcionalidades da table control serão: inserir registro, excluir registro, marcar
todos os registros e desmarcar todos os registros. Para criar os botões, utilize a tabela 3.5 para
definir os atributos dos botões:
Tabela 3.5
Funcionalidad Nome Nome íconeComprimento Código de Função
e Definido/Visív
el
Inserir PB_300_INS ICON_INSERT_ROW 7/2 FN_300_INS
ICON_DELETE_RO
Excluir PB_300_DEL W 7/2 FN_300_DEL
Marcar PB_300_MARCAR ICON_SELECT_ALL 7/2 FN_300_MARCAR
PB_300_DESMARCA ICON_DESELECT_AL FN_300_DESMARCA
Desmarcar R L 7/2 R
Insira os botões na parte abaixo da table control, conforme demonstrado na figura abaixo:
Como referência na criação do botão, consulte o tópico 'Criar Botão – PB_ABRIR_100' na

página 15.
Ao término da criação dos botões, ative a tela.
153
Tratamento dos códigos de função da Table Control – Tela 300
No evento PAI da tela 300, será tratado os códigos de função dos botões de manipulação da
table control. Os botões de inserir, excluir, marcar e desmarcar os registros serão tratados
dentro do módulo USER_COMMAND_0300 no evento PAI.
Será necessário codificar o código conforme a tela abaixo. A rotina específica de cada código
de função será inserida dentro de vários Forms, cada um para cada rotina. Insira o código
marcado dentro do módulo:
Crie cada um dos forms apresentados na figura acima dentro da include ZCADMAT_F01 e insira
os códigos conforme as figuras abaixo:
 FORM INSERIR_REGISTRO_300
154
 FORM EXCLUIR_REGISTRO_300
 FORM MARCAR_REGISTRO_300
155
 FORM DESMARCAR_REGISTRO_300
Validação dos campos da table control
Da mesma forma como foi feita a validação do campo Fornecedor na tela 100, é possível
também validar os campos da table control. Na table control será realizada as seguintes
validações:
Campo Material – Irá verificar se o material é valido, ou seja, existe no sistema e preencher o
campo descrição automaticamente.
Tipo de material – Irá verificar se o tipo de material informado á válido.
Setor Industrial – Irá verificar se o setor industral é válido.
Unidade de medida básica – Irá verificar se a unidade de medida básica é valida.
Se em qualquer um dos campos a condição não for atendida, o usuário deverá receber uma
mensagem de erro na tela e o cursor deverá estar posicionado no campo correspondente.
A validação dos campos da table control é realizada no evento PAI, pois é o evento que é
acionado quando o usuário dispara uma ação na tela. Para a validação, será utilizando o
comando de tela FIELD na lógica de processamento.
A sintaxe do comando FIELD é:
FIELD <campo_da_tela> MODULE <nome_do_módulo> ON <condição>.
A condição pode ser ON INPUT ou ON REQUEST.
156
A diferença entre as condições do comando FIELD são:
ON INPUT – O módulo <nome_do_módulo> é chamado quando o valor do campo for diferente

de vazio. Independentemente da modificação do valor do campo, o módulo será chamado.
ON REQUEST – O módulo <nome_do_módulo> é chamado quando o valor do campo é

alterado. Se o usuário, por exemplo, teclou Enter e o valor do campo está inalterado, o módulo
não será chamado.
Para utilizar o comando de tela FIELD para validar um campo da table control, será necessário
utilizá-lo dentro do bloco de comando LOOP da table control pretendida.
Utilizando o programa ZCADMAT como exemplo, o comando FIELD deverá ficar dentro do
bloco de LOOP da table control TC_MATERIAL, conforme o código abaixo, para que o campo
seja validado linha a linha. Se a condição definida dentro de um módulo não for atendida, será
emitida uma mensagem de erro (Tipo E) para o usuário, e somente o campo problemático
permanecerá aberto. Com isso, o usuário sabe qual o campo deve ser corrigido e na linha
correta.
Segue abaixo os módulos contendo o código de validação para cada um dos campos
mencionados. Os módulos deverão ser criados na include I01 (CADMAT_I01) e os forms no
include F01 (ZCADMAT_F01).
A validação será efetuada nas tabelas de verificação informada na tabela MARA.
157
Validação do campo TI_MATERIAL-MATNR
158
Validação do campo TI_MATERIAL-MTART
159
Validação do campo TI_MATERIAL-MBRSH
160
Validação do campo TI_MATERIAL-MEINS
161
Alterar os atributos dos elementos de tela em tempo de execução
Como foi visto anteriormente, quando os elementos de tela são adicionados na tela, é possível
alterar os atributos dos elementos tais como manter um campo aberto ou fechado, o
conteúdo de um campo intensificado ou ocultar um botão.
Além da possibilidade de definir os atributos no desenvolvimento da tela, também é possível

defini-los em tempo de execução, ou seja, dependendo de uma determinada condição, um
campo, um botão, ou um conjunto de elementos podem ter seus atributos modificados.
Para o programa ZCADMAT, dependendo da transação utilizada, os campos dos dados dos
fornecedores ficarão abertos quando a transação for ZMAT02 e ficarão fechadas quando a
transação for ZMAT03. Os campos da tabela de materiais também terão o mesmo
comportamento.
Para definir os atributos dos elementos de tela em tempo de execução, será necessário
manipular os dados da tabela SCREEN dentro do ABAP. A tabela SCREEN possui os seguintes
componentes:
Tabela 4.1
Componente Tamanho Tipo Descrição
NAME 132 CHAR Nome do campo da tela
GROUP1 3 CHAR Grupo de modificação 1
REQUIRED 1 CHAR Campo de entrada é obrigatório
INPUT 1 CHAR O campo está pronto para entrada

OUTPUT 1 CHAR O campo é somente de saída
INTENSIFIED 1 CHAR O campo está destacado
INVISIBLE 1 CHAR O campo é invisível
LENGTH 1 RAW Tamanho do campo
ACTIVE 1 CHAR O campo está ativo
DISPLAY_3D 1 CHAR Caixa tridimensional

VALUE_HELP 1 CHAR Apresenta o botão de ajuda de pesquisa
REQUEST 1 CHAR Entrada existe
VALUES_IN_COMB 1 CHAR Caixa de listagem
O
COLOR 10 INT4 Definição de cor do campo
O componente que terá o valor alterado para poder fechar os campos de entrada, de acordo
com a transação utilizada, será o INPUT. O valor a ser atribuído ao componente INPUT será ‘1’
162
ou ‘0’. A alteração deve ser realizada no evento PBO, pois é nesse evento que a lógica de
preparação de tela, antes de ser apresentada ao usuário, é executada.
Cada registro da tabela SCREEN está associado a um elemento de tela. Então para alterar os
atributos de um determinado elemento, será necessário ler o registro da tabela SCREEN que
contém os atributos do elemento.
O único meio de ler a tabela SCREEN é através do comando LOOP AT SCREEN. Esse comando
não aceita parâmetros. Se a tela possuir 100 elementos, a tabela será lida 100 vezes. Então
para ler o registro desejado, será necessário validar o componente ‘NOME’ com o nome do
elemento de tela desejado. Por exemplo, o campo LFA1-NAME1 terá o atributo INPUT definido
com o valor ‘1’. O código ficaria assim:
LOOP AT SCREEN.
IF screen-name = 'LFA1-NAME1'.
screen-input = '1'.
MODIFY SCREEN.
ENDIF.
ENDLOOP.
No momento que o laço conter o valor ‘LFA1-NAME1’, os valores dos componentes

especificados na tabela 4.1 são carregados e seus respectivos valores podem ser alterados. No
exemplo acima, o componente INPUT receberá o valor ‘1’ e o comando MODIFY SCREEN irá
confirmar a nova atribuição para o processador de tela. Quando o usuário abrir a tela, ele verá
que o campo estará aberto.
Esse tipo de alteração, especificando o nome do campo na validação no laço da tabela SCREEN,
torna-se muito trabalhoso em telas que possuam um grande número de campos de
entrada/saída, botões, caixas de seleção e botões de rádio. Se uma tela possuir, por exemplo,
120 desses elementos, realizar a alteração do atributo INPUT para cada um deles torna-se uma
tarefa trabalhosa. Para facilitar essa operação, é possível agrupar os campos. A tabela SCREEN
possui quatro componentes de agrupamento, são eles: GROUP1, GROUP2, GROUP3 e
GROUP4. Ou seja, é possível atribuir para um conjunto de elementos de tela até quatro grupos
simultaneamente.
Os elementos são agrupados no Screen Painter, atribuindo a identificação de grupos nos

campos Grupos, conforme a imagem abaixo.
O campo 1 refere-se ao componente GROUP1 da tabela SCREEN;
O campo 4 refere-se ao componente GROUP4 da tabela SCREEN.
1 2 3 4
163
164
Alteração dos atributos dos elementos da subtela 210
Antes de realizar a codificação para alterar os atributos dos elementos da tela dinamicamente,
será necessário agrupar os campos para facilitar a atribuição dos elementos.
Defina o grupo o valor EDT no campo GROUP1, no Screen Painter, para todos os campos de
entrada/saída da tela.
 Selecione o campo desejado
 Atribua o valor ‘EDT’ no primeiro campo do grupo

na janela de atributos
Repita o procedimento para os outros campos da tela.
Depois de agrupar os campos, será necessário inserir o código para a definição dos atributos
em tempo de execução. Os atributos dos elementos de tela serão alterados dentro do módulo
DEFINIR_ATRIBUTOS_210 no evento PBO.
Siga os procedimentos abaixo:

 Codifique a chamada do módulo
DEFINIR_ATRIBUTOS_210.
 Dê um duplo clique para criar o
módulo e ao criá-lo, especifique a
include O01(ZCADMAT_O01).
165
 Insira o código abaixo
Alteração dos atributos dos elementos da subtela 220
Antes de realizar a codificação para alterar os atributos dos elementos da tela dinamicamente,
será necessário agrupar os campos para facilitar a atribuição dos elementos.
Defina o grupo o valor EDT no campo GROUP1, no Screen Painter, para todos os campos de
entrada/saída da tela.
 Selecione o campo desejado
 Atribua o valor ‘EDT’ no primeiro campo do grupo na

janela de atributos
166
Repita o procedimento para os outros campos da tela.
Depois de agrupar os campos, será necessário inserir o código para a definição dos atributos
em tempo de execução. Os atributos dos elementos de tela serão alterados dentro do módulo
DEFINIR_ATRIBUTOS_220 no evento PBO.
Siga os procedimentos abaixo:

 Codifique a chamada do módulo
DEFINIR_ATRIBUTOS_220.
 Dê um duplo clique para criar o
módulo e ao criá-lo, especifique a
include O01(ZCADMAT_O01).
 Insira o código abaixo
167
Alteração dos atributos dos elementos da tela 300
A alteração dos atributos na tela 300 é um pouco diferente das subtelas 210 e 220, devido à
table control. O comando LOOP AT SCREEN não surte efeito na table control.
Para alterar os atributos dos campos da table control, os atributos serão alterados no controle
TC_MATERIAL, que foi criado na include TOP (ZCADMAT_TOP). O controle TC_MATERIAL está
baseada na estrutura SCXTAB_CONTROL, conforme a imagem abaixo:
Todos os componentes, com exceção do componente COLS, influem no comportamento da

table control. Por exemplo, o componente INVISIBLE = ‘1’, torna a table control invisível para o
usuário e o componente LINES contém o número de registros que a table control deve exibir.
O componente COLS possui o tipo associado à uma categoria de tabela SCXTAB_COLUMN_IT, a

qual por sua vez, possui a estrutura SCXTAB_COLUMN. Isso significa que COLS no ABAP é nada
mais do que uma tabela interna com os seguintes componentes:
168
O componente SCREEN contém a mesma estrutura utilizada nas subtelas. Os outros
componentes definem as propriedades da coluna e não do campo, por exemplo, se o
componente INVISIBLE possuir o valor ‘1’, a coluna ficará invisível.
Para definir os atributos dos campos da table control, então será necessário tratar o
componente COLS do controle TC_MATERIAL. Da mesma forma que nos elementos da tela, os
campos da table control também podem ser agrupados, basta realizar o mesmo procedimento
das subtelas 210 e 220 de agrupamento utilizando o Screen Painter. Utilize o valor ‘EDT’ para
agrupar os campos da table control com exceção do campo descrição do material, pois o
mesmo sempre deverá ficar fechado para edição.
No evento PBO, deverá ser chamado o módulo DEFINIR_ATRIBUTOS_300 e após dar o duplo
clique no módulo, criá-lo na include O01(ZCADMAT_O01). Dentro da include, insira o seguinte
código:
169
Salvar os dados de materiais do fornecedor
Os materiais do fornecedor listados na table control, poderão ser gravados na tabela

transparente ZMATERIAL.
Os materiais serão salvos na tela 200, através do código de função ‘SALVAR’, presente no
STATUS GUI chamado ‘STATUS_200’, previamente criado.
O código para salvar os dados será criado na rotina SALVAR_DADOS no módulo

USER_COMMAND_0200, no evento PAI da tela 200.
170
171

ABAP - Module Pool - ABAP Tips

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

ABAP - Module Pool - ABAP Tips

Enviado por

Direitos autorais:

Formatos disponíveis

Sumário

Um vendedor pretende realizar uma venda de um determinado material. Na criação do

Para atender tal requerimento, o programa de diálogo deve fornecer:

O ABAP/4 fornece uma variedade de ferramentas e elementos de idioma para atender os

Um programa de diálogo é consistido dos seguintes componentes básicos:

Cada diálogo em um sistema SAP é controlado pelos dynpros. Um dynpro (DYnamic

O leiaute da tela fixado no Screen Painter, determina a posição dos campos de

 ABAP/4 Module Pool

Cada tela refere-se exatamente a um programa de diálogo ABAP/4. Tal programa de

Transferência de campos de dados

Como apresentar os campos conhecidos no módulo ABAP/4 na tela? Como transferir as

Outra tarefa do processador de tela é conduzir as mensagens de erro. A verificação de

Para manter os dados consistentes em aplicações complexas, o ABAP/4 oferece técnicas

A transação TZ10 (classe de desenvolvimento SDWA) é fornecida com o sistema. Esta

Se o usuário clicar no botão Exibir, o sistema obtém os dados solicitados do banco de

Uma tela SAP é composta por vários componentes:

As abas “Período 002.2010” e “Período 012.2009” utilizam a mesma subtela.

 Caixa de diálogo modal

Ao ativar esta opção, são suportadas para a tela no tempo de execução as

Deste modo, é possível manter no sistema as entradas efetuadas na tela. No

 Desativar a compressão da tela para o tempo de execução

Se o atributo "Desativar compactação de tempo de execução" não estiver

O atributo não definido é o caso standard. Só em casos justificados se deve

Se o atributo estiver definido, a tela não é exibida na forma comprimida

A compressão é efetuada de acordo com a lógica seguinte:

 Tela-modelo - não executável

Se o atributo "tela modelo - não executável" estiver definido:

Se o atributo estiver definido, ainda são possíveis as verificações seguintes:

o verificação de síntaxe para a tela

 Manter posição de rolagem

Durante o tempo de execução de uma tela normalmente é exibida a barra de

Neste campo, tem de ser indicado de forma estática o nº da próxima tela no

A tela seguinte também pode ser determinada de forma dinâmica em um

É possível entrar uma seqüência de 4 caracteres no máximo, disponível

Se for entrado na tela de atributos do Screen Painter um grupo de telas que

Todos os elementos inseridos na tela estão presentes na lista de elementos. A lista de

Os seguintes elementos podem ser utilizados na tela:

Utilizado para fornecer ao usuário opções. Ex.: Sim/Não, Aprovado/Reprovado.

O código de função é transferido para a variável de sistema SY-UCOMM para que o

Cada botão tem sua área de subtela. No programa

Controle de Fichas (Wizard)

O quadro permite que seja

A vantagem da utilização de área de subtela é a reutilização de subtelas em comum entre

As características como quantidade de colunas, títulos de colunas, colunas fixas, linhas

Custom Control (Container)

É um elemento de tela utilizado para representar o estado de um programa graficamente. O

Um pequeno trecho de código tenha os seguintes comandos:

Diferentemente dos programas ABAP, a lógica de processamento não contém declaração

A lógica de processamento é como um programa ABAP o qual é utilizado como um container

PROCESS BEFORE OUTPUT.

PROCESS AFTER INPUT.

 PROCESS BEFORE OUTPUT (PBO) é automaticamente ativado depois do

 PROCESS ON HELP-REQUEST(POH) e PROCESS ON VALUE_REQUEST(POV) são

Dentro dos eventos de bloco, os seguintes comandos podem ser utilizados:

Referência a um campo. É possível

LOOP Inicia o processamento em LOOP

Ações do usuário na tela

Existem várias maneiras de o usuário interagir com as telas.

Preenchimento de campos de entrada

 Selecionando um botão na tela

 O código de função de um botão, campo de seleção, botão de rádio ou caixa de

Se o campo OK_CODE na lista de elementos possui um nome (e conseqüentemente está

O evento PAI é sempre disparado quando o usuário redimensiona a tela contendo os

Processamento de campos de entrada/saída