Fórum Preciso de sugestões sobre método de programação ... #214663
17/02/2004
0
Olá, senhores e senhoras...
Imaginem a seguinte situação:[list:374bd052f9][*:374bd052f9]Uma tabela de Clientes;
[*:374bd052f9]Campos calculados;
[*:374bd052f9]e procedimentos de eventos.[/list:u:374bd052f9]
Um dos campos indispensáveis, para mim, é o campo CalcLayOut, que mostra como quero ver a descrição do cliente: nome fantasia, nome precedido de tratamento pessoal (Dr. Fulano), Razão Social, etc.
Outro é o CalcEndereco: Tipo do Logradouro (rua, avenida, praça, etc.) + espaço (quando necessário) + Logradouro + vírgula (quando necessário) + Número + vírgula (quando necessário) + complemento (apartamento, bloco, etc.) ;
Na linha de baixo (o campo neste caso sai como um memo) vão: CEP (quando informado) + hífem (quando necessário) + Cidade + hífem (quando necessário) + Estado.
Um evento: BeforePost... Não posso aceitar um cliente com um [Código] que já existe. Posso aceitar homonimos, mas não códigos iguais. Ou C.P.F. iguais em registros diferentes (o que nem tem lógica).
Dá para perceber que cada TQuery é envolvido por inúmeras linhas de código.
Uso várias expressões SQL que me filtram os registros, mas sempre sobre a mesma tabela e sempre precisando das mesmas características. Na verdade, hoje eu tenho uma função para a qual envio uma nova cláusula WHERE que é substituída na propriedade SQL do TQuery. Tal função me retorna, inclusive, o valor antigo, caso precise de um filtro apenas temporário e, então, voltar à forma antiga.
Exemplos de uso: [list:374bd052f9][*:374bd052f9]Estou olhando o cadastro de contas a receber, constato alguns atrasos e preciso ver as fichas destes clientes... [*:374bd052f9]Mas já estou vendo uma outra ficha, já que posso estar faturando para um segundo cliente qualquer... [*:374bd052f9]Além disso, posso querer comparar a ficha de dois, três ou mais clientes ao mesmo tempo, então eu abro várias vezes o formulário TCadClientes, que é a visualização completa de tais dados.[/list:u:374bd052f9]
Sendo assim, logicamente, minhas aplicações são sempre MDIs.
OK... Cá está a questão: não posso, simplesmente, usar um único componente TQuery lá no meu DataModule. Se o abrir para um formulário, estarei desorganizando a leitura de um outro qualquer.
Também, não posso criar inúmeros TQuerys usando os mesmos procedimentos de eventos e utilitários. Nem mesmo seira gerenciável...[list:374bd052f9]
Então, como usar todas as características deste componente TQuery sem ficar repetindo os códigos ou tendo o trabalho de religar eventos e demais modificações?[/list:u:374bd052f9]
Hoje, eu uso um TFrame, no qual coloco um TQuery e todos os métodos e eventos especiais que desenvolvi. Aliás, faço isso para Clientes, Fornecedores, Produtos... Cada qual com suas devidas programações. Em todos os casos, minha TQuery interna sempre chama, simplesmente, Q !
Assim, quando coloco este TFrame no formulário de cadastro de clientes, por exemplo, ele é visto como um componente único e especial, herdando todas as características de seu antecessor e melhor: posso aumentar suas características para um formulario preservando tudo o que já foi criado.
Eu referencio a TQuery, neste caso, como Clientes.Q (acho que fica até elegante). Se quero um campo: Clientes.QNomeCompleto, Clientes.QCidade, Clientes.QTelefonePrincipal, etc.
Alguém tem uma sugestão mais prática ou lógica ou inteligente ou tudo isso de uma só vez?
Agradeço muito a ajuda, porque sei que deve ser uma questão difícil, misturando programação, propriamente dita, com política de programação... Fico devendo.
Imaginem a seguinte situação:[list:374bd052f9][*:374bd052f9]Uma tabela de Clientes;
[*:374bd052f9]Campos calculados;
[*:374bd052f9]e procedimentos de eventos.[/list:u:374bd052f9]
Um dos campos indispensáveis, para mim, é o campo CalcLayOut, que mostra como quero ver a descrição do cliente: nome fantasia, nome precedido de tratamento pessoal (Dr. Fulano), Razão Social, etc.
Outro é o CalcEndereco: Tipo do Logradouro (rua, avenida, praça, etc.) + espaço (quando necessário) + Logradouro + vírgula (quando necessário) + Número + vírgula (quando necessário) + complemento (apartamento, bloco, etc.) ;
Na linha de baixo (o campo neste caso sai como um memo) vão: CEP (quando informado) + hífem (quando necessário) + Cidade + hífem (quando necessário) + Estado.
Um evento: BeforePost... Não posso aceitar um cliente com um [Código] que já existe. Posso aceitar homonimos, mas não códigos iguais. Ou C.P.F. iguais em registros diferentes (o que nem tem lógica).
Dá para perceber que cada TQuery é envolvido por inúmeras linhas de código.
Uso várias expressões SQL que me filtram os registros, mas sempre sobre a mesma tabela e sempre precisando das mesmas características. Na verdade, hoje eu tenho uma função para a qual envio uma nova cláusula WHERE que é substituída na propriedade SQL do TQuery. Tal função me retorna, inclusive, o valor antigo, caso precise de um filtro apenas temporário e, então, voltar à forma antiga.
Exemplos de uso: [list:374bd052f9][*:374bd052f9]Estou olhando o cadastro de contas a receber, constato alguns atrasos e preciso ver as fichas destes clientes... [*:374bd052f9]Mas já estou vendo uma outra ficha, já que posso estar faturando para um segundo cliente qualquer... [*:374bd052f9]Além disso, posso querer comparar a ficha de dois, três ou mais clientes ao mesmo tempo, então eu abro várias vezes o formulário TCadClientes, que é a visualização completa de tais dados.[/list:u:374bd052f9]
Sendo assim, logicamente, minhas aplicações são sempre MDIs.
OK... Cá está a questão: não posso, simplesmente, usar um único componente TQuery lá no meu DataModule. Se o abrir para um formulário, estarei desorganizando a leitura de um outro qualquer.
Também, não posso criar inúmeros TQuerys usando os mesmos procedimentos de eventos e utilitários. Nem mesmo seira gerenciável...[list:374bd052f9]
Então, como usar todas as características deste componente TQuery sem ficar repetindo os códigos ou tendo o trabalho de religar eventos e demais modificações?[/list:u:374bd052f9]
Hoje, eu uso um TFrame, no qual coloco um TQuery e todos os métodos e eventos especiais que desenvolvi. Aliás, faço isso para Clientes, Fornecedores, Produtos... Cada qual com suas devidas programações. Em todos os casos, minha TQuery interna sempre chama, simplesmente, Q !
Assim, quando coloco este TFrame no formulário de cadastro de clientes, por exemplo, ele é visto como um componente único e especial, herdando todas as características de seu antecessor e melhor: posso aumentar suas características para um formulario preservando tudo o que já foi criado.
Eu referencio a TQuery, neste caso, como Clientes.Q (acho que fica até elegante). Se quero um campo: Clientes.QNomeCompleto, Clientes.QCidade, Clientes.QTelefonePrincipal, etc.
Alguém tem uma sugestão mais prática ou lógica ou inteligente ou tudo isso de uma só vez?
Agradeço muito a ajuda, porque sei que deve ser uma questão difícil, misturando programação, propriamente dita, com política de programação... Fico devendo.
Ildefonso
Curtir tópico
+ 0
Responder
Posts
18/02/2004
Ildefonso
...Alguma sugestão, gente?
Responder
Gostei + 0
19/02/2004
Delmar
Amigo, nunca utilizei a passagem que um dia li, mas lembrei que eventualmente pode ser uma alternativa para seu caso.
Dominando o Delphi 4 ´A Bíblia´ de Marco Cantù. Editora Makron Books.
Cap 12 - Acesso avançado a banco de dados
Sobre o tópico: Um aplicativo MDI com modos de visualização não sincronizados.
Não sei se as novas versões trazem este tópico ou o complementaram.
Sintese da idéia: ´Se seu modulo de dados tem apenas uma Tquery que executa consultas diversas sobre várias tabelas físicas e vc precisa manter o conjunto de dados no dataset ao executar novamente uma outra instrução sql sobre o mesmo objeto Tquery, então poder-se-ia criar uma nova cópia do datamodule para cada execução. Quando não mais desejar manter os dados no dataset, então o datamodule poderia ser ´destruído´.
Estes datamodules não seriam criados automaticamente e, sim, sob demada em cada criação de um novo formulário onde as instâncias dos novos datamodules seriam atribuidos a uma variável local, para evitar confusão com instancias de datamodules com visão global.
Todos os controles de reconhecimento de dados seriam conectados com a origem dos dados no datamodule recentemente criado.
Isso é apenas política de programação, pode ser que não lhe sirva como solução. Fica a idéia.
Um abraço
Delmar
Dominando o Delphi 4 ´A Bíblia´ de Marco Cantù. Editora Makron Books.
Cap 12 - Acesso avançado a banco de dados
Sobre o tópico: Um aplicativo MDI com modos de visualização não sincronizados.
Não sei se as novas versões trazem este tópico ou o complementaram.
Sintese da idéia: ´Se seu modulo de dados tem apenas uma Tquery que executa consultas diversas sobre várias tabelas físicas e vc precisa manter o conjunto de dados no dataset ao executar novamente uma outra instrução sql sobre o mesmo objeto Tquery, então poder-se-ia criar uma nova cópia do datamodule para cada execução. Quando não mais desejar manter os dados no dataset, então o datamodule poderia ser ´destruído´.
Estes datamodules não seriam criados automaticamente e, sim, sob demada em cada criação de um novo formulário onde as instâncias dos novos datamodules seriam atribuidos a uma variável local, para evitar confusão com instancias de datamodules com visão global.
Todos os controles de reconhecimento de dados seriam conectados com a origem dos dados no datamodule recentemente criado.
Isso é apenas política de programação, pode ser que não lhe sirva como solução. Fica a idéia.
Um abraço
Delmar
Responder
Gostei + 0
20/02/2004
Ildefonso
Olá, Delmar.
Entendi a sugestão. Afinal, um DataModule não é nada mais que um formulário especial e, como tal, pode ser criado e mantido por uma variável.
Mas, em meu caso, há formulários que usam várias tabelas, tal como um formulário de faturamento: Clientes, Produtos, Faturas e FaturasItens, além de algumas complementares.
Por outro lado, há formulários que usam apenas a tabela - ou query - Produtos mais uma tabela auxiliar. Mesmo assim, em um determinado momento, preciso comparar dois produtos (não raro, um de meus clientes compara os dados de quatro produtos ao mesmo tempo). Neste caso, eu não precisaria de um objeto pesado como uma instância do DataModule, declarando um total de 45 tabelas.
Dessa forma, para ter a pulverização necessária, imaginei a seguinte situação: um DataModule para cada tipo de Conjunto de Dados.
Teria, então, o DMProdutos, DMClientes, DMFornecedores, etc. De acordo com minha necessidade os declararia na cláusula [b:84692428fd]uses[/b:84692428fd] e faria sua criação no [b:84692428fd]OnCreate[/b:84692428fd] do formulário que os usa.
Será que isto é viável?
Entendi a sugestão. Afinal, um DataModule não é nada mais que um formulário especial e, como tal, pode ser criado e mantido por uma variável.
Mas, em meu caso, há formulários que usam várias tabelas, tal como um formulário de faturamento: Clientes, Produtos, Faturas e FaturasItens, além de algumas complementares.
Por outro lado, há formulários que usam apenas a tabela - ou query - Produtos mais uma tabela auxiliar. Mesmo assim, em um determinado momento, preciso comparar dois produtos (não raro, um de meus clientes compara os dados de quatro produtos ao mesmo tempo). Neste caso, eu não precisaria de um objeto pesado como uma instância do DataModule, declarando um total de 45 tabelas.
Dessa forma, para ter a pulverização necessária, imaginei a seguinte situação: um DataModule para cada tipo de Conjunto de Dados.
Teria, então, o DMProdutos, DMClientes, DMFornecedores, etc. De acordo com minha necessidade os declararia na cláusula [b:84692428fd]uses[/b:84692428fd] e faria sua criação no [b:84692428fd]OnCreate[/b:84692428fd] do formulário que os usa.
Será que isto é viável?
Responder
Gostei + 0
23/02/2004
Delmar
Se será viável?
Como disse, nunca usei, apenas lembrei que pode ser uma alternativa.
Vc deve equacionar uma solução e testar. Se funcionar e não degradar sua performance, OK, será viável.
Um abraço
Como disse, nunca usei, apenas lembrei que pode ser uma alternativa.
Vc deve equacionar uma solução e testar. Se funcionar e não degradar sua performance, OK, será viável.
Um abraço
Responder
Gostei + 0
24/02/2004
Farmy Ferreira
nosso amigo demar tem razão, vc deveria equalizar melhor sua apicação, pois nem sempre conseguimos uma ba performance, quando temos requisitos complexos para trabalhar.
Vc alé de poder rever sua aplicação nes metodo, não pensou em rever seu banco de dados? vc pode obtar por banco de dados relacionais, que possuam o contexto de views e transações, o que acontece nestes casos é que:
* O sgbd isola cada usuário em uma transação evitando conflito no acesso aos dados;
* E o conceito de views possibilita que dados de varias tabelass diferentes possam ser visualizados, sem bloquear registros, podendo utilizar joins e gruop by nas clausulas SQL sem problemas, o que não é comum nas views é o fato de se realizae um update ou insert nos dados visualizados;
* Vc ainda pode realizar uma migração de componentes que evite muitos acessos ao banco de dados, caso do Dbexpress, que faz cache dos dados da tabela, e os manipula sem retornar ao servidor de dados, isso economiza trafego na rede 9se for seu caso), e permite que varios formularios visualizem os dados ou copiem os dados de forma temporaria (não muito elegante) para serem trabalhados.
então amigo vc poderia não só rever a suas tecnicas do ponde vista da aplicação, como também rever o banco de dados e os componentes utilizados.. lembre-se que existe o ´live-data´, tecnologia da borland para facilitar acessos a dados sem que vc fique preso a um bd especifico.
um UFA!!
(UFA!! = Um Forte Abraço!!!).
Vc alé de poder rever sua aplicação nes metodo, não pensou em rever seu banco de dados? vc pode obtar por banco de dados relacionais, que possuam o contexto de views e transações, o que acontece nestes casos é que:
* O sgbd isola cada usuário em uma transação evitando conflito no acesso aos dados;
* E o conceito de views possibilita que dados de varias tabelass diferentes possam ser visualizados, sem bloquear registros, podendo utilizar joins e gruop by nas clausulas SQL sem problemas, o que não é comum nas views é o fato de se realizae um update ou insert nos dados visualizados;
* Vc ainda pode realizar uma migração de componentes que evite muitos acessos ao banco de dados, caso do Dbexpress, que faz cache dos dados da tabela, e os manipula sem retornar ao servidor de dados, isso economiza trafego na rede 9se for seu caso), e permite que varios formularios visualizem os dados ou copiem os dados de forma temporaria (não muito elegante) para serem trabalhados.
então amigo vc poderia não só rever a suas tecnicas do ponde vista da aplicação, como também rever o banco de dados e os componentes utilizados.. lembre-se que existe o ´live-data´, tecnologia da borland para facilitar acessos a dados sem que vc fique preso a um bd especifico.
um UFA!!
(UFA!! = Um Forte Abraço!!!).
Responder
Gostei + 0
24/02/2004
Farmy Ferreira
desculpe-me é Delmar.. foi mal amigo
Responder
Gostei + 0
25/02/2004
Ildefonso
Olá, Farmy.
Meu problema não está em velocidade ou visibilidade ou conhecimento sobre banco de dados + SQL.
Meu problema é que minha aplicação exige que um mesmo formulário seja aberto ´n´ vezes. Dessa forma, sua fonte de dados deve ser apontada de maneira livre: um formulário está vendo o registro do Delmar, o outro está vendo o registro do Farmy.
O uso de um TFrame me permite ´carregar´ tudo que eu quero. Gostaria de saber se há alguma outra forma de definir estes super objetos que usarei em uns sete formulários diferentes.
Os ´views´ do meu SGBD são intensamente programados com campos calculados, justo para serem mais rápidos - os campos tipo LookUps são muito pesados - e para fazerem cálculos em cima de cálculos. Por exemplo, o campo Sexo armazena ´F´ ou ´M´, mas o CalcSexo mostra ´Feminino´ ou ´Masculino´. Anexo a isso, quando é ´F´, o campo CalcLayout mostraria Senhora Fulana, quando igual a ´M´, mostraria Senhor Fulano, a não ser que sejam menores de idade, pois seriam, então, tratados como O Jovem ou A Jovem.
Este é um banco de dados para auxílio a marketing, e apresentação é fundamental...
Quando formulei a primeira questão era para pedir sugestões para utilizar a O.O. 100¬. Já que eu tenho uma consulta - ou view ou query ou dataset ou sabe-se lá como iremos chamar os registros amanhã - gostaria que ela e toda a programação embutida fossem consideradas um componente que eu possa carregar para qualquer lugar que eu precise: SEM NENHUMA PROGRAMAÇÃO SIGINIFICATIVA. Tal como outro componente qualquer do Delphi, que a gente herda, modifica e usa já de maneira customizada.
Aliás, já testei: se eu colocasse os campos calculados em STORE PROCEDURES no banco de dados, estaria enviando o triplo de dados pela rede, sendo que os campos calculados via evento OnCalculate são sob demanda. Se, por um acaso, a tabela for muito grande, haverão registros que não serão mostrados e, portanto, não será disparado o evento para eles... muito mais econômico.
Agradeço os comentários e as opiniões e continuo esperando outras... 8)
Meu problema não está em velocidade ou visibilidade ou conhecimento sobre banco de dados + SQL.
Meu problema é que minha aplicação exige que um mesmo formulário seja aberto ´n´ vezes. Dessa forma, sua fonte de dados deve ser apontada de maneira livre: um formulário está vendo o registro do Delmar, o outro está vendo o registro do Farmy.
O uso de um TFrame me permite ´carregar´ tudo que eu quero. Gostaria de saber se há alguma outra forma de definir estes super objetos que usarei em uns sete formulários diferentes.
Os ´views´ do meu SGBD são intensamente programados com campos calculados, justo para serem mais rápidos - os campos tipo LookUps são muito pesados - e para fazerem cálculos em cima de cálculos. Por exemplo, o campo Sexo armazena ´F´ ou ´M´, mas o CalcSexo mostra ´Feminino´ ou ´Masculino´. Anexo a isso, quando é ´F´, o campo CalcLayout mostraria Senhora Fulana, quando igual a ´M´, mostraria Senhor Fulano, a não ser que sejam menores de idade, pois seriam, então, tratados como O Jovem ou A Jovem.
Este é um banco de dados para auxílio a marketing, e apresentação é fundamental...
Quando formulei a primeira questão era para pedir sugestões para utilizar a O.O. 100¬. Já que eu tenho uma consulta - ou view ou query ou dataset ou sabe-se lá como iremos chamar os registros amanhã - gostaria que ela e toda a programação embutida fossem consideradas um componente que eu possa carregar para qualquer lugar que eu precise: SEM NENHUMA PROGRAMAÇÃO SIGINIFICATIVA. Tal como outro componente qualquer do Delphi, que a gente herda, modifica e usa já de maneira customizada.
Aliás, já testei: se eu colocasse os campos calculados em STORE PROCEDURES no banco de dados, estaria enviando o triplo de dados pela rede, sendo que os campos calculados via evento OnCalculate são sob demanda. Se, por um acaso, a tabela for muito grande, haverão registros que não serão mostrados e, portanto, não será disparado o evento para eles... muito mais econômico.
Agradeço os comentários e as opiniões e continuo esperando outras... 8)
Responder
Gostei + 0
25/02/2004
Delmar
Olá, Delmar.
Entendi a sugestão. Afinal, um DataModule não é nada mais que um formulário especial e, como tal, pode ser criado e mantido por uma variável.
Mas, em meu caso, há formulários que usam várias tabelas, tal como um formulário de faturamento: Clientes, Produtos, Faturas e FaturasItens, além de algumas complementares.
Por outro lado, há formulários que usam apenas a tabela - ou query - Produtos mais uma tabela auxiliar. Mesmo assim, em um determinado momento, preciso comparar dois produtos (não raro, um de meus clientes compara os dados de quatro produtos ao mesmo tempo). Neste caso, eu não precisaria de um objeto pesado como uma instância do DataModule, declarando um total de 45 tabelas.
Dessa forma, para ter a pulverização necessária, imaginei a seguinte situação: um DataModule para cada tipo de Conjunto de Dados.
Teria, então, o DMProdutos, DMClientes, DMFornecedores, etc. De acordo com minha necessidade os declararia na cláusula [b:e6bc581d14]uses[/b:e6bc581d14] e faria sua criação no [b:e6bc581d14]OnCreate[/b:e6bc581d14] do formulário que os usa.
Será que isto é viável?
Quantos datamodules vc tem neste momento em sua aplicação?
É possível modularizar o datamodule (DM) em vários. Até acho que é uma boa política depositar um conjunto de datasets, que tendem ser abertos conjuntamente em uma mesma interface ou em um conjunto de interfaces, em um DM. Usar outros DMs para depositar outro conjunto de datasets, que tendem ser abertos em outro conjunto mais especifico de telas e, assim por diante.
Uma vez que seu problema não é desempenho, para não ficar apenas no teórico e lhe encorrajar a particionar o DM em vários, temos uma aplicação, que já tem 6 ou 7 DMs completamente ocupados (imagina a dificuldade de encontrar um objeto se todos objetos estivem acomodados sobre um único DM) . Isto significa que temos algumas centenas de Tquerys, Tstoredprocedures, Tdatasources e Ttransactions (usamos IBO)
e o aplicativo tem bom desempenho até sobre PCs Pentium 133, 16 MB e Win 98, com rede 10 Mbps.
Assim, particionando o DM, vc poderia separar exatamente como pensou
<<para ter a pulverização necessária, imaginei a seguinte situação: um DataModule para cada tipo de Conjunto de Dados.
Teria, então, o DMProdutos, DMClientes, DMFornecedores>>
Inicie fazendo para um deles. Assim, quando fosse instanciado um novo DM, vc não estaria criando os 45 objetos que estão acomodados sobre seu DM e, sim, criando apenas o objeto que precisa mostrar mais de um registro corrente.
Mas lembro que a iniciativa deve ser sua. Em programação, uma idéia pode solucionar bem uma necessidade, mas pode não servir em outro caso. Quando não se tem certeza, o ideal é fazer um backup de todo programa (fontes, dbs etc) no ponto que se está, e testar a idéia. Se não der certo, vc restaura o backup e continua procurando por outra solução.
Por outro lado, vc pode esperar por outras idéias, mas tmb não há garantias de que haverá outra idéia melhor. Ou seja, enquanto não vem outra idéia, vc poderia ir testando a que lhe passei.
A gente só quer ajudar da melhor forma possível. Seu caso, ainda não tem uma solução pronta porque deve ser a primeira vez no Fórum. Até por isso que as idéias são raras....
Sucesso. Vamos acreditar que juntos podemos chegar a uma boa solução.
Um forte abraço e tenha calma que uma hora a gente chega lá.
Responder
Gostei + 0
29/02/2004
Farmy Ferreira
Desculpe-me por não ter compreendido seu problema anteriormente, o que vc diz estar enfrentado é por causa da utilização de frames que contem seus objetos de acesso a dados, por isso quando vc necessita criar uma tela semelhante a uma já existente, vc deve reconfigurar seus objetos ou dissabilitar os que não serão utilizados, certo?
minha sugestão iguala-e a o delmar, e a sua observação, mas observe que o data module deve ser criado antes do formulario, para que os componentes existente nos mesmo possam apontar para ele sem erro. Conforme seus clientes fossem visualizando dados diferesntes, vc podeia instanciar estes ´DMs´ de acordo com suas necessidades, ou até mesmo no DM, criar apenas os objetos que vc neccecita naquele momento, lembre-se que o DM é um formulario como outros no delphi.
espero ter ajudado.
minha sugestão iguala-e a o delmar, e a sua observação, mas observe que o data module deve ser criado antes do formulario, para que os componentes existente nos mesmo possam apontar para ele sem erro. Conforme seus clientes fossem visualizando dados diferesntes, vc podeia instanciar estes ´DMs´ de acordo com suas necessidades, ou até mesmo no DM, criar apenas os objetos que vc neccecita naquele momento, lembre-se que o DM é um formulario como outros no delphi.
espero ter ajudado.
Responder
Gostei + 0
29/02/2004
Tarcisiojr
caro amigo acho q ja passei pelo seu problema e resolvi da seguinte forma. eu tinha q abrir o mesmo form varias vezes o q eu fiz. 1o todos os tables e querys tinham q esta no form e nao do datamodule pois eu iria criar o form em run time. ai eu fiz o seguinte codigo
-----------------------
fmcliente1: tform;
begin
fmcliente1:=tfmclientemodelo.create(application);
fmcliente1.show;
fmcliente1.free;
end;
no caso tfmclientemodelo eh um form q eu crei como modelo pra criar uma instancia deles rum time ai aqui deu certo blz...
-----------------------
fmcliente1: tform;
begin
fmcliente1:=tfmclientemodelo.create(application);
fmcliente1.show;
fmcliente1.free;
end;
no caso tfmclientemodelo eh um form q eu crei como modelo pra criar uma instancia deles rum time ai aqui deu certo blz...
Responder
Gostei + 0
29/02/2004
Ildefonso
Olá, Tarcisio.
Agradeço o interesse. Mas esta parte de recriar os formulários prontos eu já sabia.
Afinal, quando o Delphi cria os códigos sobre a variável (o tal de Application.CreateForm(TForm1, Form1) já dá pra desconfiar que todo o Form cabe em um variável.
Mas vou colocar o problema de outra forma:[list:7ccbe527be][*:7ccbe527be]A base de dados acessa Clientes e formata seus campos, inclusive com cosntrução de ventos que cuidam da validação da entrada de dados;
[*:7ccbe527be]Preciso criar sete tipos diferentes de formulários que acessam a mesma base de dados de clientes...
[list:7ccbe527be][*:7ccbe527be]O próprio formulário de cadastro,
[*:7ccbe527be]Um formulário de consultas rápidas, tal como os ´Contatos do Outlook´,
[*:7ccbe527be]Um formulário de pedidos,
Etc.[/list:u:7ccbe527be][*:7ccbe527be]Em todos os casos, deve haver um ponteiro diferente para cada acesso.[/list:u:7ccbe527be]
Por que isso? Porque posso estar agendando uma reunião com um clientes, enquanto estou faturando um pedido para outro.
Dessa forma, preciso de todos os dados dos clientes a disposição, mas olhando vários pontos da tabela ao mesmo tempo.
Por isso uso o TFrame. Criei ali tudo o que preciso: campos calculados, regras de validação, funções auxiliares para pesquisa, etc.
Quando preciso criar um formulário que acesse os dados de clientes, basta colocar o TFrame que tudo fica disponível e ´PARITUCLAR´ ao formulário no qual inseri o componente frame.
Na teoria, se tenho quinze formulários diferentes, posso colocar o frame neles sem interferência, tal como colocamos os outros componentes TDBEdit, TDBComobox, TDBText, etc.
Assim, eu gostaria de saber se há outro método para conseguir o mesmo benefício (modularidade, orientação a objetos, praticidade...).
Agradeço as sugestões e vamos continuar a discutir.
8) :lol: :roll:
Agradeço o interesse. Mas esta parte de recriar os formulários prontos eu já sabia.
Afinal, quando o Delphi cria os códigos sobre a variável (o tal de Application.CreateForm(TForm1, Form1) já dá pra desconfiar que todo o Form cabe em um variável.
Mas vou colocar o problema de outra forma:[list:7ccbe527be][*:7ccbe527be]A base de dados acessa Clientes e formata seus campos, inclusive com cosntrução de ventos que cuidam da validação da entrada de dados;
[*:7ccbe527be]Preciso criar sete tipos diferentes de formulários que acessam a mesma base de dados de clientes...
[list:7ccbe527be][*:7ccbe527be]O próprio formulário de cadastro,
[*:7ccbe527be]Um formulário de consultas rápidas, tal como os ´Contatos do Outlook´,
[*:7ccbe527be]Um formulário de pedidos,
Etc.[/list:u:7ccbe527be][*:7ccbe527be]Em todos os casos, deve haver um ponteiro diferente para cada acesso.[/list:u:7ccbe527be]
Por que isso? Porque posso estar agendando uma reunião com um clientes, enquanto estou faturando um pedido para outro.
Dessa forma, preciso de todos os dados dos clientes a disposição, mas olhando vários pontos da tabela ao mesmo tempo.
Por isso uso o TFrame. Criei ali tudo o que preciso: campos calculados, regras de validação, funções auxiliares para pesquisa, etc.
Quando preciso criar um formulário que acesse os dados de clientes, basta colocar o TFrame que tudo fica disponível e ´PARITUCLAR´ ao formulário no qual inseri o componente frame.
Na teoria, se tenho quinze formulários diferentes, posso colocar o frame neles sem interferência, tal como colocamos os outros componentes TDBEdit, TDBComobox, TDBText, etc.
Assim, eu gostaria de saber se há outro método para conseguir o mesmo benefício (modularidade, orientação a objetos, praticidade...).
Agradeço as sugestões e vamos continuar a discutir.
8) :lol: :roll:
Responder
Gostei + 0
Clique aqui para fazer login e interagir na Comunidade :)