Alguém decidiu correr em background uma ALV editável. Deu dump. A solução é simples mas pouco óbvia.

Hoje em dia é raro usar o CL_GUI_ALV_GRID porque uso quase sempre a SALV. Mas quando é preciso fazer ALVs editáveis continuo a recorrer à CL_GUI_ALV_GRID. Durante muito tempo julguei que, para a usar, tinha de criar um ecrã com um container, o que é uma chatice. E como eu uso ABAP OO, precisava de criar um function group para alojar o ecrã e um function module para o chamar, o que era outra chatice.

Às vezes é nas coisas mais básicas que se perde mais tempo. Por exemplo, recentemente foi preciso que uma ALV grid ocupasse automaticamente a janela inteira. Mas como? Mas como? Mas como?

Não sei há quanto tempo é que isto está disponível mas só agora descobri que é muito fácil ver numa ALV o conteúdo de uma tabela interna durante debug.

A lei do menor esforço, esse grande axioma da Humanidade, tem, no mundo da programação, a particularidade de, em muitos casos, acabar por ser simplesmente a lei do esforço adiado. Porque é muito provável que algo que tenha sido desenvolvido de acordo com esta lei venha mais tarde a precisar de um grande esforço extra. Seja dos utilizadores que vão utilizar esse algo ou dos programadores que mais tarde terão de o manter.

Atire a primeira pedra aquele que não se deixou guiar por esta lei ao desenvolver este ou aquele programas.

Eu não atiro.

Quando queres usar a CL_GUI_ALV_GRID num CONTAINER tens de copiar um GUI Status standard de outro programa. Por exemplo o GUI Status “STANDARD" do grupo de funções SALV. E depois no PAI do ecrã chamas:

SET PF-STATUS ‘STANDARD’.

E lá aparecem os butõezinhos.

É comum encontrar as estruturas de dados das ALVs declaradas explicitamente no código. Quando isto é feito, o catálogo de campos tem de ser criado manualmente. Se em vez disso se usar uma estrutura pré-definida (do DDIC ou como TYPE), o catálogo de campos pode ser criado automaticamente. Esta abordagem é sempre melhor resultando em menos código, mesmo que o catálogo de campos tenha de ser reajustado aqui e ali. https://abapinho.

As classes SALV são mais versáteis e sofisticadas do que os antigos módulos de função. Portanto, para ALVs novas, usa sempre a SALV. Excepção feita para ALVs que precisem de editar os dados pois nesse caso as SALV ainda são muito pouco capazes. https://scn.sap.com/docs/DOC-10365 https://scn.sap.com/docs/DOC-10366

A não ser que queiras fazer edição dos dados, a única forma digna de usar ALVs nos dias que correm é através das classes SALV. São mais modernas, mais elegantes e permitem a quem as usa alcançar um estatuto social até aqui apenas ao alcance daqueles que são donos de uma matrícula de carro.

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 é.

À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.