lookup automatico

Sugestões
#1

Yuri

Coisa simples, mas que evita digitar a mesma coisa sempre:

No lookup do campo temos opção manual e automatica, o automatica temos que digitar ou montar a SELECT, eu tenho um caso que o nome do cliente é constantemente usado/visualizado no automatico e temos que sempre digitar o mesmo SELECT, se criar uma nova opção para colocar Função PHP (Metodo) pegando de biblioteca.

então no lookup teriamos 3 opções automatico, manual, e funções

ou outra ideia salvar o SELECT , da mesmo forma que é feito no manual.

Entendeu ?

Ari

#2

Função PHP???

Desculpa, mas não vejo sentido…

Você pode salvar a lista manual e reutiliza-la.
Automático tem que ser um select que retorne duas colunas, uma que é o valor do campo, e a outra que é a exibição na lista docampo (Select, Radio, CheckBox).

Ao gerar o fonte, o SC, monta essa lista dinamicamente usando o retorno do Select (SQL) digitado, não cabe qualquer outro tipo de código aqui.

#3

Pense em repetir o mesmo SELECT umas 50 vezes… acho que até mais que isso vou usar.

Se tá guardado até como se fosse um lookup manual, ganha tempo.

Ari

#4

Então…
Por volta de 2007, eu tinha sugerido um senhor dicionário de dados, e previa isso, vc definia no dicionario de dados tipo de campo, o lookup dele, códigos dos eventos onfocus, onchange, onblur, formatação, valores iniciais, etc… aí toda vvez que adicionasse esse campo a uma app, ele já viria com todo o código pronto, mas infelizmente isso não evoluiu

Risos… foi em 2006: http://www.netmake.com.br/forum/index.php/topic,330.msg892.html#msg892

#5

Eu acho Ari que poucas pessoas utilizariam o mesmo select 50x+, um exemplo disso foi uma aplicação que fiz que eu criei 32 blocos e um select controlava quantos iriam aparecer, eu recorri ao fórum para saber se tinha algo que escondia blocos dinamicamente e automaticamente, não existia, só existia uma macro e eu teria que fazer um case com 32 linhas e nada dinâmico, então o Haroldo me deu uma ideia de usar JQuery, e eu consegui fazer uma função que faria automaticamente, não importando o número de blocos que eu criasse.

Quase ninguém vai usar 32 blocos em uma aplicação, o que eu quero dizer é que certas coisas temos que desenvolver um método alternativo, pois a NM não vai realizar sugestões que vão beneficiar uma ou 2 pessoas. Eles vão trabalhar para melhorar a ferramenta em coisas que beneficiariam a maioria dos usuários.

#6

Ari, longe de mim querer questionar sua metodologia de desenvolvimento porém, fiquei curioso quanto a isso que você disse de ter que usar o mesmo lookup em mais de 50 apps.

Talvez não seria o caso de você tentar resumir suas apps, talvez por montar forms um pouco mais complexos mas que contemplem uma quantidade maior de dados e relacionamentos, ou talvez rever seu DB e a sua estrutura dos dados, se há repetição desnecessária de informações.

Sei que é inevitável repetir códigos neste modelo de desenvolvimento, mas é inevitável também adequarmos nossa metodologia a essa realidade pra ficar viável desenvolver com a ferramenta.

#7

mais uma vez obrigado, nao queria causar polemica…mas acho ainda que é coisa simples

é estou na medida do possivel, mudando alguns conceitos, mas minha aplicação desktop, é bem grande: só de relatorio tem mais de 190, é um aplicativo antigo no mercado, desde 1993 na rua… então tenho que melhorar mas tambem manter compatibilidade com ideias antigas, meus usuarios são duro na queda…qualquer coisa que mudar que nao for de agrado, já vem porrada.

E nao somente para um segmento de mercado, tem varios ramos de atividade, com as mais variadas formas de tratar as coisas, desde um simples fluxo de caixa que passei apouco até relatorio de produtos bem simples, Quando se faz um sistema sob medida tipo “terno sob medida” a coisa é bem diferente. Outro dia no curso, encontrei uns colegas que nem sabia que nos sistemas antigos usava-se o enter para navegar de campo a campo, nao existia o TAB, os caras tem 25 anos de idade… eu com 47… falar de telas DOS, isso é meio que DINOSSAURO mesmo…mas eu tenho cliente com mais de 15 anos comigo.

Tem varios relatorios de peças que tenho que mostrar o nome da marca, pegando do fornecedor e se eu fizer join ou outro tipo de ligação no SQL, pode ser penoso, a base de dados tem cara que tem mais um milhao de registro, juntando com outra de fornecedores, mesmo com where dá carga no MySQL e muitos casos prefiro buscar o nome da marca caso a caso, no lookup mesmo, porque com a paginação isso nao pésa…

Eu acho que no final quando eu converter todo o sistema para Web, deve ter mais de 900 aplicações, já estou com 383

tem relatorio que consegui reduzir, colocando mais opções de filtros, mas realmente nao sei como isso vai funcionar na pratica, ele(usuario) pode achar que tem muita coisa tem usuario que quer telas diretas e objetivas, sei das vantagens desta ferramenta…

toda esta quantidade de relatorios foram criadas com o tempo, é impossivel saber se usam todos.

Por isso, eu te falo tem lookup que tenho que repetir mesmo.

Ari

#8

Boa tarde,

Repassei sua sugestão para nossa equipe de desenvolvimento. O nosso canal direto para sugestões é o sugestao@netmake.com.br

att,
Bernhard Bernsmann