Comportamento de Lista Dinâmica



  • Olá pessoal.

    Estou migrando um sistema para o Maker. Eu fiz um fluxo para controlar a exibição de alguns componentes no formulário da seguinte maneira: quando um funcionário for motorista, será exibido no formulário o componente Número da CNH, Categoria, Validade, uma Moldura e um Label; caso ele não seja motorista, esses mesmos componentes não serão exibidos.

    O fluxo funcionou perfeitamente quando navego no formulário, exibindo ou ocultando os componentes, conforme o campo Função do Funcionário sofre alterações, já que coloquei o fluxo no evento "Ao Modificar" do componente lista dinâmica de Função do Funcionário. Veja na figuras 1 e 2 que estão abaixo.
    [attachment=2]1.jpg[/attachment] [attachment=1]2.jpg[/attachment]
    O fluxo funciona corretamente ao navegar nos registros, já que o componente Lista Dinâmica tem o seu conteúdo modificado, disparando o fluxo (que está no evento ao Modificar da Lista Dinâmica). Quando o conteúdo continua o mesmo na navegação entre registros, nada é alterado. Ótimo. Veja o fluxo que usei:
    [attachment=0]3.jpg[/attachment] Até aí, tudo bem. Mas, quando vou incluir um NOVO registro, e seleciono a função MOTORISTA, por exemplo, o fluxo é executado como se o novo valor da lista fosse NULL (em branco). Aí, eu seleciono COBRADOR, e o fluxo mais uma vez se comporta de forma errada, recebendo o valor anterior à alteração, nesse caso, MOTORISTA, e não o valor atual, após a modificação.

    Aí eu fui investigar os valores do componente Lista Dinâmica que estavam sendo pegos pela função "Obter Valor da Lista Dinâmica" e notei que, quando em modo de edição, quando eu altero o valor da lista dinâmica, selecionado outro item, o valor que é pego pela função "Obter Valor da Lista Dinâmica" é sempre o anterior à alteração realizada, e não o que acabei de selecionar (o atual). Assim, se eu clicar em [b]COBRADOR [/b]e o item que estava selecionado antes for [b]VENDEDOR[/b], o valor que a função "Obter Valor da Lista Dinâmica" recebe é [b]COBRADOR (o valor antigo)[/b]. Se eu selecionar agora o item [b]MOTORISTA[/b], o valor que é recebido pela função será [b]COBRADOR[/b]. Isso tem feito com que os componentes se comportem de maneira errada durante a edição (inserção ou alteração), exibindo ou ocultando os componentes em momentos inoportunos.

    [b]Minha pergunta é: ALGUÉM JÁ EXPERIMENTOU ESSA SITUAÇÃO NO MAKER?[/b]
    Pergunto porque acho que o evento "ao modificar" deveria enviar o valor atual do componente (pós alteração) e não o antigo. Correto? Pelo menos no Delphi é assim e quando estou apenas navegando nos registros do formulário criado em maker ele se comporta dessa maneira, mostrando o valor pós-modificação do componente.

    Algum colaborador da Softwell poderia testar e ver se o retorno da função está funcionando como deveria? Ou o retorno do valor antes da alteração seria o esperado do evento? Se sim, qual o evento ideal para obter o valor pós-alteração?

    Obrigado a todos e até mais.
    Abraço!


  • Utilize a função, obter valor do componente... ela pega o índice da mesma.


  • O índice para mim não é interessante, pois a função de motorista pode estar cadastrada com outros códigos no banco de dados, já que se trata de uma lista dinâmica. Ela pode estar cadastrada no banco como código 1, 2, 3, ..., o que interfere no índice da lista. O ideal seria obter o nome da função do funcionário e verificar se é motorista.

    Obs: O índice é retornado corretamente, com o valor pós-alteração ao usar a função "obter valor do componente". O mesmo deveria acontecer com a função "Obter Valor da Lista Dinâmica".


  • Pois é.. foi por isso que falei..


    Em relação ao nome, se ele pode ter outro código no banco, ele pode ser cadastrado com outro nome também não é? Isso não pode gerar um problema?
    veja isso direito, pois o usuário cadastra do jeito que quer...


  • O usuário não vai cadastrar a função VIGILANTE para um motorista, concorda? Assim, quando a função do funcionário contiver a palavra motorista (pode ser motorista, motorista avulso, motorista de ambulância) o sistema vai exibir os campos da CNH. É simples assim. E essas informações são de uma tabela auxiliar, que serão alimentadas na instalação do software, com o código gerado automaticamente.

    O que você não pode é deixar de implementar um recurso solicitado pelo cliente por falha no ambiente de desenvolvimento.
    É o sistema que deve se adequar às necessidades do cliente, e não o cliente se adequar ao sistema.


  • Se você diz que é alimentado automaticamente, então os códigos tem que ser iguais, certo? Se vc responder que não, então você está usando a função "Número aleatório para definir seu ID", fora isso, não vejo outra possibilidade.

    Outra coisa.. confiar na digitação do usuário é, no mínimo, ingenuidade sua. Se vacilar, usuário escreve "MOTORISSTA", aí sua comparação por texto já era.
    E digo mais, do jeito que você montou o fluxo, utilizando a função "Igual", quando o usuário cadastrar motorista avulso, motorista de ambulância, como você mesmo citou, não irá funcionar.. você teria que obter a subsequência...

    Repense a solução e agradeça a função não se comportar do jeito que você gostaria.

    "[i]O que você não pode é deixar de implementar um recurso solicitado pelo cliente por falha no ambiente de desenvolvimento.
    É o sistema que deve se adequar às necessidades do cliente, e não o cliente se adequar ao sistema[/i]
    ."
    E isso que vc falou acima.. não faz o menor sentido. O usuário pede pra você fazer.. mas COMO se faz, quem diz é VOCÊ, ele não manda você comparar strings na aplicação.


  • Pra seu conhecimento, eu já mudei anteriormente o fluxo para que ele pegue a sequência, e assim funcionará tanto para motorista como para motorista de ambulância, auxiliar de motorista, motorista de trator, motorista de jatinho... Ou seja, o ingênuo aqui não sou eu. Talvez você tenha alguma limitação e não compreenda. Não me venha falar de ingenuidade quando você mesmo é que não entende o que espero da minha postagem, que seria que um colaborador da softwell tivesse conhecimento do comportamento do evento e corrigisse o problema. Afinal, se houver um bug, serei o primeiro a solicitar a resolução, pois paguei pelo maker e espero que ele se comporte como esperado. Se você não pode resolver o problema, ou não sabe (até porque não é colaborador da softwell), não poste respostas, por gentileza. Se abstenha de fazê-lo. Afinal, não estou aqui para que me ensinem como programar, apenas postei a pergunta porque a documentação relativa aos eventos é, no mínimo, escassa. Afinal, você deve ter os seus programinhas para cuidar ao invés de perder seu tempo dando pitaco onde não foi chamado.

    Em tempo: Eu não disse que a alimentação é automática. Eu disse que o cadastro é feito na instalação, onde o usuário irá cadastrar pela primeira vez as funções desempenhadas. E se houver erro de digitação, é só ir no cadastro de funções e corrigir. Simples assim. Os códigos não são iguais. Em que mundo você vive? Códigos de chave primária iguais? Você já ouviu falar em tipo serial no postgresql? Pois é. Se o cliente inserir um motorista com o código 1 e excluí-lo, ou incluir um vendedor como sendo código 1, o próximo motorista e demais funções de funcionários cadastradas nunca mais terão valor 1... É nisso que se baseiam as sequences: incrementação automática. Caso não conheça o tipo serial, consulte o manual do banco de dados. É aí que o seu argumento de usar índice cai por terra. O índice muda de acordo com a posição dos registros na tabela (sabe o que é uma lista dinâmica?). O que eu não posso é obrigar o cliente a manter a função de motorista no índice 1 da lista para que o meu fluxo funcione. Ou então contratar mãe Dinah para ela prever em que posição da tabela o cliente vai cadastrar todas as funções de motoristas.

    Peço a gentileza de não responder mais a este tópico, pois não tenho tempo para perder com você.

    Grato.


  • Ri alto com isso.

    [i]"Em tempo: Eu não disse que a alimentação é automática. Eu disse que o cadastro é feito na instalação, onde o usuário irá cadastrar pela primeira vez as funções desempenhadas. E se houver erro de digitação, é só ir no cadastro de funções e corrigir. Simples assim. Os códigos não são iguais. Em que mundo você vive? Códigos de chave primária iguais? Você já ouviu falar em tipo serial no postgresql? Pois é. Se o cliente inserir um motorista com o código 1 e excluí-lo, ou incluir um vendedor como sendo código 1, o próximo motorista e demais funções de funcionários cadastradas nunca mais terão valor 1... É nisso que se baseiam as sequences: incrementação automática. Caso não conheça o tipo serial, consulte o manual do banco de dados. É aí que o seu argumento de usar índice cai por terra. O índice muda de acordo com a posição dos registros na tabela (sabe o que é uma lista dinâmica?). O que eu não posso é obrigar o cliente a manter a função de motorista no índice 1 da lista para que o meu fluxo funcione. Ou então contratar mãe Dinah para ela prever em que posição da tabela o cliente vai cadastrar todas as funções de motoristas."[/i]



    Sem stress, meu caro. Utilizo o fórum apenas para ajudar. Parece que dessa vez não deu. :)
    De resto, boa sorte.


  • [quote="edsoncabral"]
    Até aí, tudo bem. Mas, quando vou incluir um NOVO registro, e seleciono a função MOTORISTA, por exemplo, o fluxo é executado como se o novo valor da lista fosse NULL (em branco). Aí, eu seleciono COBRADOR, e o fluxo mais uma vez se comporta de forma errada, recebendo o valor anterior à alteração, nesse caso, MOTORISTA, e não o valor atual, após a modificação.

    Aí eu fui investigar os valores do componente Lista Dinâmica que estavam sendo pegos pela função "Obter Valor da Lista Dinâmica" e notei que, quando em modo de edição, quando eu altero o valor da lista dinâmica, selecionado outro item, o valor que é pego pela função "Obter Valor da Lista Dinâmica" é sempre o anterior à alteração realizada [/quote] Por questão de sincronia, o fluxo é disparado e executado muito antes do texto ser trocado. Use agendar execução do fluxo para obter o valor da lista dinâmica

Log in to reply