COMO ACESSAR TEXTBOX DE UMA FUNCAO STATIC?
Tenho um método public Static Iniciar() num form Filho1 que é acionada pelo form MDI principal. Nela inicio os processo de inclusão de registros deste form, que consiste em Habilitar e Limpar os campos do formulário, mas não está funcionando, pois um método statico não consegue acessar os controles no próprio formulário.
Pesquisei muito na web e quando encontro um post igual ao meu, a resposta diz que já resolveu, mas não dá a solução. [Ô]Adoro[Ô] quando quem pergunta não compartilha a solução que descobre.
Alguém pode me ajudar?
[b/Código tudo no mesmo formulário[/b]
public static void Iniciar() // este método é chamado pelo form MDI por isso tem que ser public static
{
LimparCampos(); // Não funcona, nem se eu trocar private por public no método
HabilitarCampos(true); // Não funciona
}
private void Limpar() // Nota: Não posso colocar também como static, pois se fizer não tenho acesso aos controles
{
txtDepartamento.Text = String.Empty;
txtNomeResponsavel.Text = String.Empty;
chkInativo.Checked = false;
}
private void HabilitarCampos(bool Acao)
{
txtDepartamento.Enabled = Acao;
txtNomeResponsavel.Enabled = Acao;
chkInativo.Enabled = Acao;
}
Pesquisei muito na web e quando encontro um post igual ao meu, a resposta diz que já resolveu, mas não dá a solução. [Ô]Adoro[Ô] quando quem pergunta não compartilha a solução que descobre.
Alguém pode me ajudar?
[b/Código tudo no mesmo formulário[/b]
public static void Iniciar() // este método é chamado pelo form MDI por isso tem que ser public static
{
LimparCampos(); // Não funcona, nem se eu trocar private por public no método
HabilitarCampos(true); // Não funciona
}
private void Limpar() // Nota: Não posso colocar também como static, pois se fizer não tenho acesso aos controles
{
txtDepartamento.Text = String.Empty;
txtNomeResponsavel.Text = String.Empty;
chkInativo.Checked = false;
}
private void HabilitarCampos(bool Acao)
{
txtDepartamento.Enabled = Acao;
txtNomeResponsavel.Enabled = Acao;
chkInativo.Enabled = Acao;
}
Qual o motivo deste método ter de ser estático? A única forma seria passando o formulário como parâmetro para o método, mas se fosse pra fazer isso seria mais fácil tornar o método não estático
A finalidade é que ele é chamado por um botão (Barra de Ferramentas Genérica do MDI Pai). Estou criando uma barra padrão para todos os formulário, assim ao clicar no botão Incluir do MDI ele irá acionar o método Iniciar do formulário filho que estiver aberto.
Cada formulário filho terá um método public static Iniciar() de modo a preparar o formulário para o novo cadastro (limpar campos, habilitar campos, etc...).
Esse método static é passado por delegate ao botão, só assim ele consegue acionar o método ao ser clicado.
Nota: O motivo disso é não ter que criar em todos os formulários os mesmos botões: Incluir, alterar, consultar, gravar, imprimir, etc.... que ocupam muito espaço, ná com uma barra de ferramentas padrão, como todo aplicativo hoje tem, fica muiot mais fácil e organizado, melhorando inclusive o layot do aplicativo. Toda parte complicada do código já consegui fazer:
Lista para saber qual form está aberto no momento;
Criar os delegates para os botões padrão e também para o método close de cada formulário, que é passado ao clicar no menu do MDI pai;
Alterar o estado dos botões padrão, pelo médoto fechar do form filho;
Acessar o método Iniciar do filho, pelos botões do MDI pai.
Agora a coisa que teoricamente seria a mais fácil, o prórpio formulário alterar as propriedades de seus controles, não estou conseguindo pelo método statico. Tentei algumas coisas e não funcionárão.
Cada formulário filho terá um método public static Iniciar() de modo a preparar o formulário para o novo cadastro (limpar campos, habilitar campos, etc...).
Esse método static é passado por delegate ao botão, só assim ele consegue acionar o método ao ser clicado.
Nota: O motivo disso é não ter que criar em todos os formulários os mesmos botões: Incluir, alterar, consultar, gravar, imprimir, etc.... que ocupam muito espaço, ná com uma barra de ferramentas padrão, como todo aplicativo hoje tem, fica muiot mais fácil e organizado, melhorando inclusive o layot do aplicativo. Toda parte complicada do código já consegui fazer:
Lista para saber qual form está aberto no momento;
Criar os delegates para os botões padrão e também para o método close de cada formulário, que é passado ao clicar no menu do MDI pai;
Alterar o estado dos botões padrão, pelo médoto fechar do form filho;
Acessar o método Iniciar do filho, pelos botões do MDI pai.
Agora a coisa que teoricamente seria a mais fácil, o prórpio formulário alterar as propriedades de seus controles, não estou conseguindo pelo método statico. Tentei algumas coisas e não funcionárão.
De um método estático, você só poderá acessar métodos estáticos. Já pensou em OOP para essa finalidade?
Eu diria que o uso de métodos estáticos não é a melhor forma neste caso, o ideal seria você usar Interfaces e deixar o MDI Pai detectar se o form filho implementa ou não a interface.
é bem simples, mas daria um pouco de trabalho explicar pelo fórum, então fiz um pequeno exemplo com dois forms filho e dois botões em um toolbar, quando o botão é clicado ele chama o método correto do form filho caso ele implemente a interface necessária
Detalhes importantes aqui é que caso você tenha vários botões que sempre vão ser implementados nos forms você pode colocar todas as funções em uma mesma interface, no exemplo eu criei duas interfaces apenas para demonstrar, mas se por exemplo os forms que usem alguns botões tipo inserir, editar, deletar e salvar sempre usam estes quatro botões então você pode criar quatro funções na mesma interface.
é bem simples, mas daria um pouco de trabalho explicar pelo fórum, então fiz um pequeno exemplo com dois forms filho e dois botões em um toolbar, quando o botão é clicado ele chama o método correto do form filho caso ele implemente a interface necessária
Detalhes importantes aqui é que caso você tenha vários botões que sempre vão ser implementados nos forms você pode colocar todas as funções em uma mesma interface, no exemplo eu criei duas interfaces apenas para demonstrar, mas se por exemplo os forms que usem alguns botões tipo inserir, editar, deletar e salvar sempre usam estes quatro botões então você pode criar quatro funções na mesma interface.
Você poderia usar polimorfismo para resolver esse problema.
Crie um form mdichild padrao, implemente uma interface com um metodo --> limpar nele, depois faça os outros forms herda-lo.
Para usa-lo, é só verificar se o mdichild ativo implementa a interface. Caso sim, execute o metodo.
Crie um form mdichild padrao, implemente uma interface com um metodo --> limpar nele, depois faça os outros forms herda-lo.
Para usa-lo, é só verificar se o mdichild ativo implementa a interface. Caso sim, execute o metodo.
Fiz um projeto aqui com exemplo para salvar e limpar os campos.
No menu --> novo, você cria os forms child
No menu --> Editar, você pode limpar os campos
Testa ai e nos dê uma posição
vlw
No menu --> novo, você cria os forms child
No menu --> Editar, você pode limpar os campos
Testa ai e nos dê uma posição
vlw
Caro LUIS HERRERA
Talves falta uma mudança só de conceito
Olhe sua aplicação
Se está dentro do seu formulário o erro esta em chamada externa para dentro do seu método que é pegar as funções construida fora e trazer para dentro......
O correto como o colega KERPLUNK comentou sobre OOP talvez o o mais correto a se fazer no seu caso
Uma Classe com seus objeto ou funções de Limpar e Habilitar para ser chamada pelo processo ou evento cada form nos dois métodos por CLASSE ou por FORM.............
Olhe meu exemplo bem simples com suas funções
Sendo executada dentro do FORM BOTÃO FUNÇÃO DO FORM
Sendo Executada Pela Classe BOTÃO FUNÇÃO DA CLASSE
SE CRIAR A CLASSE NÃO PRECISA REPLICAR CÓDIGO NOS FORMS FICA AMAIS FÃCIL DE APLICAR MANUTENÇÃO E EVITA REDUNDÂCIA NO CÓDIGO...........
Nãop repara na estética mas acho que isso pode resolver seu problema
Talves falta uma mudança só de conceito
Olhe sua aplicação
Citação:[b/Código tudo no mesmo formulário[/b]
Se está dentro do seu formulário o erro esta em chamada externa para dentro do seu método que é pegar as funções construida fora e trazer para dentro......
O correto como o colega KERPLUNK comentou sobre OOP talvez o o mais correto a se fazer no seu caso
Uma Classe com seus objeto ou funções de Limpar e Habilitar para ser chamada pelo processo ou evento cada form nos dois métodos por CLASSE ou por FORM.............
Olhe meu exemplo bem simples com suas funções
Sendo executada dentro do FORM BOTÃO FUNÇÃO DO FORM
Sendo Executada Pela Classe BOTÃO FUNÇÃO DA CLASSE
SE CRIAR A CLASSE NÃO PRECISA REPLICAR CÓDIGO NOS FORMS FICA AMAIS FÃCIL DE APLICAR MANUTENÇÃO E EVITA REDUNDÂCIA NO CÓDIGO...........
Nãop repara na estética mas acho que isso pode resolver seu problema
Tinha me esquecido também que no caso de usar MenuStrip e ToolStrip é possÃvel usar o recurso de merge deles, de forma que você adiciona um ToolStrip direto no form filho e faz ele se mesclar ao do form pai
Bom dia amigos, primeiro quero agradecer muito a todos pela grande ajuda, muito obrigado de coração.
1- Jaba - infelizmente meu VS é 2008 e não consegui testar seu código. Mesmo trocando a versão no .sln não funcionou. De qualquer modo obrigado pela ajuda.
Alessandro e OCELOT - acredito que ambas as soluções de vocês são excelentes e resolvem muito bem meu problema. Porém seria possÃvel vocês explicarem qual a difernça entre as duas soluções, usar Interface ou Classe Intermediária?
Importanta: Não quero criar nenhum problema entre os dois colegas, de qual solução é melhor etc.., mas como são duas formas bem diferentes, acredito que haja situações onde um seja melhor e em outras a segunda seja mais interessante. Assim poderia saber quando empregar uma ou a outra.
A parte de interface, eu sinceramente não tinha entendido direito até hoje. Tinha lido que seu uso obrigava um form a implementar a estrutura definida, mas como usar na prática não havia visto. Pelo que havai lido, este recurso é interessante para forçar a criação do método em todos os forms, mas pelo que và no exemplo ele só é obrigatório se estiver associado na public partial class frmFilho2 : Form de cada formulário. Então não se associa a interface como um todo, mas sim a cada método contidos nela?
Já o exemplo da Classe intermediária, isso permitiria a criação de todos os métodos de todos os formulários nesta classe de modo bem genérico, reduzindo o código, bem como facilitando a manutenção como disse o Alessandro.
[b/OCELOT - [/b] você poderia exemplificar como funcionaria essa parte de associação [Ô]Mesclar[Ô] itens do menuStrip especÃficos de cada formulário? Isso parece bem interessante, tipo um formulário especÃfico poderia ter uma função só dele e ao ser aberto o menu associado a ele, incorporaria este menu do form filho. é isso mesmo?
1- Jaba - infelizmente meu VS é 2008 e não consegui testar seu código. Mesmo trocando a versão no .sln não funcionou. De qualquer modo obrigado pela ajuda.
Alessandro e OCELOT - acredito que ambas as soluções de vocês são excelentes e resolvem muito bem meu problema. Porém seria possÃvel vocês explicarem qual a difernça entre as duas soluções, usar Interface ou Classe Intermediária?
Importanta: Não quero criar nenhum problema entre os dois colegas, de qual solução é melhor etc.., mas como são duas formas bem diferentes, acredito que haja situações onde um seja melhor e em outras a segunda seja mais interessante. Assim poderia saber quando empregar uma ou a outra.
A parte de interface, eu sinceramente não tinha entendido direito até hoje. Tinha lido que seu uso obrigava um form a implementar a estrutura definida, mas como usar na prática não havia visto. Pelo que havai lido, este recurso é interessante para forçar a criação do método em todos os forms, mas pelo que và no exemplo ele só é obrigatório se estiver associado na public partial class frmFilho2 : Form de cada formulário. Então não se associa a interface como um todo, mas sim a cada método contidos nela?
Já o exemplo da Classe intermediária, isso permitiria a criação de todos os métodos de todos os formulários nesta classe de modo bem genérico, reduzindo o código, bem como facilitando a manutenção como disse o Alessandro.
[b/OCELOT - [/b] você poderia exemplificar como funcionaria essa parte de associação [Ô]Mesclar[Ô] itens do menuStrip especÃficos de cada formulário? Isso parece bem interessante, tipo um formulário especÃfico poderia ter uma função só dele e ao ser aberto o menu associado a ele, incorporaria este menu do form filho. é isso mesmo?
Caro LUIS HERRERA,
tente criar um novo projeto no vs2008 e depois adicionar cada item desse meu projeto para o novo projeto. Desta forma, eu acho que você conseguirá testar o meu projeto.
Com relação a diferença referente à parte da implementação desse problema, eu acho que usando os princÃpios da POO (polimorfismo nesse caso) seria a melhor forma, pois todo incremento ou alteração estará bem claro para quem for mexer nesse código no futuro (inclusive para voce mesmo), bastando apenas sobrescrever os métodos polifórmicos.
vlw
tente criar um novo projeto no vs2008 e depois adicionar cada item desse meu projeto para o novo projeto. Desta forma, eu acho que você conseguirá testar o meu projeto.
Com relação a diferença referente à parte da implementação desse problema, eu acho que usando os princÃpios da POO (polimorfismo nesse caso) seria a melhor forma, pois todo incremento ou alteração estará bem claro para quem for mexer nesse código no futuro (inclusive para voce mesmo), bastando apenas sobrescrever os métodos polifórmicos.
vlw
Tópico encerrado , respostas não são mais permitidas