Cortar e inserir rapidamente
Lá aprendi mais uma pequena funcionalidade obscura do SAPGui. Como acelerar o corte e costura.
Lá aprendi mais uma pequena funcionalidade obscura do SAPGui. Como acelerar o corte e costura.
Durante muitos anos, quando entrava em discussões sobre ABAP OO ser melhor do que FORMs, INCLUDEs e CALL FUNCTIONs, o mais comum é a pessoa do lado de lá continuar convencida de que OO é bom nas outras linguagens mas não traz vantagens para o ABAP. Logo a começar pelo atroz código standard SAP que parece ter sido escrito para provar que é possível fazer algo que viola todas as boas prácticas de programação e mesmo assim funciona.
Não, o ABAP nunca vai ter o operador NOT.
O Abapinho não tem falado muito sobre o 7.40 porque as suas novidades têm já sido amplamente descritas em vários sites. Tentamos não inventar a roda. Mas há pequenas pérolas úteis que ainda são pouco conhecidas. Esta é sobre uma delas.
Em SQL consegue-se obter os valores únicos de um campo recorrendo ao DISTINCT. Quando os dados já estão numa tabela interna, antes do ABAP 7.40 tinha de se fazer um LOOP e um COLLECT. Mas agora que vivemos em tempos mais modernos, há uma forma simples e elegante que consegue o mesmo com um único comando.
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?
Nos anos 80, quando eu era pequenino, tinha de fazer LOAD "" e depois esperar vários minutos a olhar para riscas numa TV e a ouvir ruído antes que um jogo do ZX Spectrum ficasse pronto a jogar. Muito anos mais tarde, quando já tinha um PC, descobri um emulador que tinha um menu com centenas de jogos do ZX Spectrum. Só tinha de escolher um da lista e começar a jogar instantaneamente.
Sempre usei * para comentar o código. Só usava " quando precisava de usar pseudo-comentários ou adicionar um pequeno comentário no final da linha. Mas há pouco tempo aprendi que faz muito mais sentido usar “.
O gestor de versões do ABAP é muito mau. Para além de todos os seus defeitos, ele não permite de forma fácil saber quem fez o quê e quando. O git, que é um gestor de versões a sério, permite obter essa informação facilmente através da sua ferramenta git-blame. Devido a isto, muitos ABAPers habituaram-se a acrescentar o seu nome e data a todas as linhas de código que acrescentam, que apagam e que alteram. Assim, à medida que um programa ABAP vai sendo mais modificado, mais ilegível se vai tornando e mais difícil é navegar entre versões para saber quem fez o quê.
Hoje debruçamo-nos sobre como tentar optimizar o código para transformar um SELECT num RANGE.
Há alguns anos atrás mostrei como se podia converter uma MESSAGE normal numa excepção tipificada. Entretanto o ABAP evoluiu um bocadinho e agora, na versão 7.40, aquela solução complexa já não é necessária.
Quem lê o Abapinho sabe que eu defendo o uso e abuso do ABAP Package Concept. Hoje em dia a primeira coisa que eu faço quando começo um desenvolvimento novo é criar-lhe um pacote encapsulado que guardará todos os seus objectos que, nos casos mais complexos, será um pacote “Main” ainda subdividido em vários sub-pacotes. Fica aqui a minha modesta proposta para criar uma árvore de pacotes Z que ajude a organizar aquilo que é normalmente uma confusão danada.
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.