Num relatório, os valores são normalmente pedidos ao utilizador no ecrã de selecção inicial, antes da execução do programa. Mas e se quiseres pedir-lhe mais alguns valores, interactivamente, a meio da execução do programa?

Uma forma de o fazer é criar um ecrã com os campos desejados e depois invocá-lo com CALL SCREEN. Mas desenhar o ecrã e definir o PAI e o PBO é uma valente maçada.

Outra solução é recorrer às funções POPUP_GET_VALUES ou POPUP_GET_VALUES_DB_CHECKED. São bastante versáteis mas ainda assim algo chatas de utilizar e com algumas limitações.

Mas há uma forma mais simples de o fazer. É através do CALL SELECTION-SCREEN. Passo a explicar:

Primeiro há que definir o ecrã de selecção. A sua definição é praticamente igual à do ecrã de selecção inicial de um relatório:

TABLES: t001.

SELECTION-SCREEN BEGIN OF SCREEN 3000.
PARAMETERS: p_uname TYPE syuname.
SELECT-OPTIONS: p_bukrs FOR t001-bukrs.
SELECTION-SCREEN END OF SCREEN 3000.

Depois, onde quer que te apeteça invocar o ecrã é só… invocares o ecrã:

START-OF-SELECTION.

* faz não sei quê antes

  CALL SELECTION-SCREEN 3000 STARTING AT 5 5.

* e mais não sei quê depois

E dá nisto:

Se meteres o STARTING AT ele vai criar uma janela de diálogo modal. Se não meteres nada, o ecrã ocupará a janela toda. O ecrã de selecção pode ser tão complicado quanto quiseres, podendo incluir abas e tudo o mais. Além disso, porque para o SAP ele não passa de um ecrã de selecção como os outros, poderás gravar variantes e tudo.

Nota que esta abordagem pode também ser usada em transacções, sendo a única desvantagem o facto de exigir F8 em vez de ENTER para submeter os valores.

Obrigado a cristinacosta pela foto.

O Abapinho saúda-vos.

Os ecrãs de selecção dos programas ABAP têm várias funcionalidades que, embora sofisticadas e simples de usar, são geralmente ignoradas. Aqui mostrar-te-ei quão simples é criar abas para melhor organizar os parâmetros de um programa. Desta vez, excepcionalmente, vou poupar-te à verborreia. É uma aula prática.
Ler o resto do artigo »

Há determinados momentos em que não é possível fazer /H para iniciar o debugger. O caso mais comum é durante uma janela de diálogo modal (aquilo que os estrangeiros chamam de popup). Mas há uma forma simples, ainda que rocambolesca, para o conseguires:

Ler o resto do artigo »

Queres obter o texto de uma mensagem da qual só sabes o ID e o número e não sabes como? Aprende aqui:

DATA texto TYPE string.
MESSAGE ID '00' TYPE 'E' NUMBER '163' WITH '123' INTO texto.

É só isto. Agora do lado de dentro da variável texto encontras o seguinte texto:

“O mandante 123 não existe no sistema”

Obrigado a Peteris B pela foto.

O Abapinho saúda-vos.

Para tentar determinar quais as profissões com gente mais preguiçosa fiz as seguintes pesquisas no Google:

Como se pode concluir inequivocamente, os engenheiros não são suficientemente preguiçosos pois são ultrapassados pelos advogados e pelos médicos. Isto tem de mudar. E esta dica vai ajudar. Mas não sem deixar clara a seguinte diferença: preguiça não é ergasiofobia. Falo aqui da preguiça nobre, a de quem gosta de fazer as coisas mas procura fazê-las com o mínimo esforço possível. Já os preguiçosos mandriões, esses não são para aqui chamados.

O SAP, que lá vai evoluindo lentamente, lançou já há uns anos um editor novo que vem cheio de capacidades muitas das quais, ainda que convenientes, são pouco aproveitadas. Uma delas chama-se “Modelos de código” que passo a apresentar:

Ler o resto do artigo »

Sabes apresentar, numa janela de diálogo, uma ALV com uma lista de registos permitindo escolha múltipla? Eu não sabia e agora já sei. Vou explicar como é.
Ler o resto do artigo »

Às vezes pergunto-me qual será, no mundo, a percentagem de código ABAP desnecessário. Um exemplo paradigmático de como se pode desperdiçar tempo a escrever código que não serve para nada e só prejudica é a tão frequente definição das descrições dos campos de uma ALV directamente em ABAP.

Ler o resto do artigo »

Por vezes um programa quer gravar um ficheiro localmente, no computador do utilizador através do SAP Gui. Nesses casos é comum que um dos campos do ecrã de selecção seja a localização da pasta no disco local.

Eis uma forma de inicializar esse campo com a pasta temporária do SAP Gui:

PARAMETERS: p_path TYPE string.

AT SELECTION-SCREEN ON VALUE-REQUEST FOR p_path.
  CALL METHOD cl_gui_frontend_services=>directory_browse
    EXPORTING
      initial_folder  = p_path
    CHANGING
      selected_folder = p_path.

INITIALIZATION.
  CALL METHOD cl_gui_frontend_services=>get_sapgui_workdir
    CHANGING
      sapworkdir = p_path.
  CALL METHOD cl_gui_cfw=>flush.

Obrigado Sérgio Fraga pela dica.

E obrigado HatM pela foto.

O Abapinho saúda-vos.

Claro que já conheces a transacção SE30 (Análise de tempo de execução) e claro que a usas amiúde para analisar programas standard e descobrir nele tabelas, funções, BADIs e quejandos.

Ora se fores como eu, manténs uma relação de amor-ódio com esta transacção: se por um lado a amas por graças a ela consegues ver as entranhas de um programa sem ter de fazer debug, por outro lado odeia-la porque normalmente a lista de entranhas costuma ter milhares de linhas e tornar-se ingerível.

Mas eu já não sou como eu porque, desde que descobri que a SE30 permite fazer análises parciais, a minha relação com ela passou a ser de puro amor. E a partir de agora também tu poderás amá-la na sua totalidade porque vou ensinar-te este segredo.

1. Transacção SE30;
2. No bloco “Restrições de medição” cria uma variante com um nome qualquer diferente do DEFAULT;
3. Na variante activa o pisco “Unidades determinadas”;
4. Insere a transacção ou programa ou módulo de função a analisar;
5. Carrega em “Executar” (normalmente agora a análise começaria mas, como escolhemos “unidades determinadas”, começa desligada e é preciso ligá-la explicitamente);
6. Navega dentro do programa que estás a analisar até chegares ao ponto que queres analisar;
7. Activa a análise escrevendo /ron lá em cima no campo de comandos;
8. Faz o que tens a fazer;
9. Desactiva a análise escrevendo lá em cima /roff;
10. Sai do programa, voltando ao ecrã da SE30.

Acabaste de fazer uma análise parcial que, em vez dos típicos milhares de linhas, tem apenas as dezenas ou centenas de linhas que ocorreram entre os comandos /ron e /roff. Mais útil, não?

Aproveita o balanço e explora as outras possibilidades disponibilizadas pelas variantes de “restrição de medição”.

Obrigado a Michael Opoczynski pelo ensinamento.

E obrigado a * Cati Kaoe * pela foto.

O Abapinho saúda-vos.

O SAP é um grande poliglota. Mas o ABAP nem sempre. O ABAP até tem muita facilidade em aprender e falar várias línguas, mas às vezes os programadores não o deixam.

Muitos programadores cinzelam os textos literais directamente no programa, deixando-o irremediavelmente incapaz de comunicar em vários idiomas. Imagino duas razões para se agrilhoar um programa a uma única língua:

• A preguiça, que é a principal razão para se fazerem as coisas mal feitas;
• A legibilidade. Realmente a forma de tornar um programa ABAP localizável é pejá-lo com referências a textos, tipo TEXT-001, o que pode torná-lo bastante ilegível.

Então aqui fica uma dica para ter o melhor dos dois mundos: um programa localizável que não perca a legibilidade:

Em vez de seres preguiçoso e fazeres:

WRITE: 'Eu quero ver auroras boreais'.

E em vez de seres obscuro e fazeres:

WRITE: TEXT-001.

Sê esperto e faz:

WRITE: 'Eu quero ver auroras boreais'(001).

E já está.

Se o text TEXT-001 estiver definido na língua em que o programa estiver a correr este TEXT-001 será usado. Caso contrário, o texto literal escrito directamente no programa será usado. Assim mantém-se a legibilidade do código, pode traduzir-se os textos à vontade e ainda por cima temos a certeza de que, mesmo quando faltar traduzir algum texto, mesmo assim aparecerá o texto que está no programa.

Obrigado Sérgio Lopes pela dica.

(E obrigado doug88888 pela foto)

O Abapinho saúda-vos.