Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Por meio dos métodos AddErro e AddWarning, são criadas mensagens que alertam sobre operações não permitidas e que devem ser revistas (AddErro), fazendo com que o usuário volte um passo nas suas ações para corrigir os itens problemáticos, ou mensagens de alertas para operações que não atendem totalmente à regra verificada, mas que não gera uma necessidade imediata de correção, permitindo que o usuário passe para a próxima etapa ou corrija o evento que gerou o aviso.

Assim, o AddErro sempre solicitará a correção do problema verificado, não permitindo ao usuário seguir em frente na operação do sistema. Por exemplo: Caso o usuário esteja inserindo ou alterando dados em um formulário e não siga a regra do negócio, no momento de salvar tais dados, o método AddErro gerará uma mensagem dizendo qual o erro ou erros a serem corrigidos, impedindo o usuário de continuar com a gravação dos dados até que os erros sejam sanados.

Já o AddWarning criará um aviso sobre o problema detetado, porém, não impedirá o usuário de gravar os dados alterados/inseridos e continue com o seu trabalho.

Para efeitos didáticos, será utilizado o Cadastro de Tomadores, onde o evento Antes de Salvar será implementado, verificando se os campos “BAIRRO” e “CODRAIS” estão preenchidos ou estão em branco.

Desenvolvendo um exemplo de AddErro e AddWarning

Neste exemplo, serão implementadas duas verificações em dois campos que não possuem crítica na regra de negócios no momento de sua gravação na tabela. Um exemplo é de um campo não obrigatório, mas importante frisar ao usuário a necessidade de informá-lo e o outro sim, obrigatório, o qual não permitirá que o usuário salve os dados caso o mesmo não seja preenchido.

Para incluir as verificações exemplificadas abaixo, o VsScripter deve ser executado e, neste exemplo específico, para o evento “Antes de Salvar”. Para tanto, o menu “Eventos via Script” deve ser acessado e, em seguida, o submenu “Antes de salvar”, conforme figura abaixo:

...

Após a escolha deste menu, será executado o formulário de desenvolvimento de “scripts” VsScripter, conforme figura abaixo:

...

 

No exemplo acima, na área de edição do código, é mostrado um texto inicial sobre o que é o Evento “AntesSalvar” e um exemplo de utilização. Este comentário pode ser excluído para o desenvolvimento do “script” alvo deste material.

Nesta área de edição serão digitados os códigos implementados pelo usuário. Os componentes visuais a direita do formulário serão explicados nas documentações apropriadas.

Descobrindo o nome do formulário a ser manipulado

Para manipular os elementos do formulário de Cadastro de Tomadores, ou qualquer outro formulário dos sistemas, é imprescindível saber o nome que identifica tal formulário. Para tanto, é necessário acessar o menu View e, em seguida, o submenu “Library Browser”. Este menu mostrará um formulário que listará todas as Classes, Funções e Constantes do formulário. Assim, é possível entender quais elementos estarão disponíveis para serem manipulados. Para o exemplo aqui, será focado na  lista de constantes, clicando em “Constants”, conforme imagem abaixo:

 

...

Na lista de constantes, é possível identificar o nome do formulário padrão dado ao Cadastro de Tomadores. Neste exemplo, o nome do formulário que facilitará a manipulação dos componentes do formulário é “FFormPadraoRHTOMADOR”.

Descobrindo informações sobre os campos dos formulários

Para facilitar o desenvolvimento dos “scripts” do VsScripter, foi desenvolvida uma funcionalidade que dá acesso ao dicionário de dados das tabelas envolvidas no formulário, bem como ao nome dado ao componente na tela.

Para acessar esses dados, deixar o campo desejado em foco, clicando com o mouse nele. Em seguida, executar o atalho CTRL+SHIT+F9, o qual abrirá outro formulário contendo os dados, conforme abaixo, que foi executado com o campo BAIRRO em foco:

...

Na área chamada Principal do formulário, na aba Propriedades, é mostrado o nome do componente no formulário, neste caso, o componente foi nomeado como “EB_BAIRRO” e o mesmo é do tipo TVsEdit.

O nome da coluna na tabela é informado na área Dados, juntamente com o nome da tabela, neste caso, a tabela é a RHTOMADOR.

Na aba Dados Tabela, é apresentado o dicionário de dados da tabela usada no formulário, neste caso, a tabela RHTOMADOR, conforme figura abaixo:

...

No grid Colunas são mostradas as colunas da tabela, com suas definições de tipo e tamanho, além de suas descrições. Ao lado, no grid Tabelas relacionadas, são mostrados os relacionamentos da tabela. Essas informações são importantes no momento da criação dos “scripts”, pois mostram exatamente quais são, como são e como utilizar os dados e elementos dos formulários.

O campo “BAIRRO” será tratado como um campo não obrigatório, porém, o usuário será alertado sobre a importância do mesmo no envio de correspondências, mas dando ao usuário a opção de continuar gravando os dados ou retornar ao formulário para indicar o valor do campo e, assim, salvar os dados.

Abaixo, segue o exemplo de código que verifica se o campo está vazio e, se estiver, gera uma mensagem no momento de salvar os dados na tabela.

Code Block
if FFormPadraoRHTOMADOR.ValorNaTela('BAIRRO') = '' then
    FFormPadraoRHTOMADOR.AddWarning(FFormPadraoRHTOMADOR.EditorDaColuna('EB_',
    'BAIRRO'), 'Campo Bairro é importante para envio de correspondência.');

O campo “CODRAIS”, que é o código do município na RAIS, será tratado como obrigatório e, caso não preenchido, o usuário não poderá salvar as alterações do registro.

Code Block
if FFormPadraoRHTOMADOR.ValorNaTela('CODRAIS') = '' then
    FFormPadraoRHTOMADOR.AddErro(FFormPadraoRHTOMADOR.EditorDaColuna('EB_',
'CODRAIS'), 'Código do município na RAIS não pode ser vazio');

Os dois exemplos de código podem ser colocados no mesmo evento, visto que ambos foram criados para serem executados pelo evento “AntesSalvar”.

Testando a implementação dos “scripts”

 Quando os “scripts” forem digitados/colados na área de edição de código, os mesmos devem parecer como na imagem abaixo:

 

...

 A indentação foi feita da forma mostrada para ficar mais fácil a visualização e leitura do código.

Para por em prática o “script” basta salvá-lo. No botão de execução, ou através do atalho “F9”, é possível executar o “script”. Neste caso, nenhuma mensagem será mostrada na execução, a menos que exista um erro de digitação ou uso dos comandos (erro de sintaxe).

Para testar a implementação do evento, basta incluir um novo tomador, ou alterar algum dado nos campos para habilitar o botão Salvar. Executando a função de “Salvar”, o “script” será executado e, caso o campo “Bairro” ou “Código do município na RAIS” estejam em branco, os respectivos eventos serão executados.

No primeiro “if”, é verificado se o valor do campo BAIRRO, retornado pelo método ValorNaTela (que lê o valor de um campo e retorna ao usuário, podendo ser usado diretamente em uma condição, ou armazenado em uma variável), está vazio. Se estiver, é gerada uma mensagem com o AddWarning que diz ao usuário que “Campo Bairro é importante para envio de correspondência”.

A mensagem é mostrada da forma abaixo, dando a oportunidade ao usuário de continuar e salvar os dados ou retornar ao formulário para correção do valor e posterior gravação dos dados, conforme figura abaixo:

...

No segundo “if”, é verificado se o campo “Código do município na RAIS” está vazio ou não. Se estiver, será gerado um evento de erro, por meio do método AddErro, que mostra a mensagem “Código do município na RAIS não pode ser vazio”. A partir deste ponto, o usuário não pode continuar e os dados não serão salvos a menos que seja feita a correção. Para tanto, o usuário deve clicar no botão “Corrigir” e preencher o campo referido. Observe que neste exemplo, o evento AddErro gera uma mensagem em vermelho para enfatizar o alerta.

...

 Observação importante: Os exemplos aqui mostrados não criticam os dados informados nos campos de exemplo. Apenas verificam se estão preenchidos ou não. Porém, é possível sim fazer uma validação personalizada dos dados informados pelos usuário, o que será mostrado na documentação adequada.