Entendendo o modelo de objetos do visual FOXPRO

Em qualquer linguagem orientada a objetos (OOL) é preciso que conheçamos o modelo de objetos ou seja a estrutura hierárquica dos objetos para que possamos obter êxito. Com Visual FoxPro esse conceito é mais válido que nunca.

O modelo de objetos pode ser considerado a um grande recipiente. Pra ficar mais claro ainda vamos comparar esse recipiente como sendo ao muro que cerca uma casa.

Esse muro possui suas características (propriedades) por exemplo, altura, largura, comprimento, espessura, cor, composição (material utilizado) e outros.

Dentro do muro há várias coisas, por exemplo uma casa, um jardim, etc.

Tanto a casa e o jardim ambos possuem suas propriedades que você mesmo pode imaginar quais são e enumerá-las.

Dentro da casa há diversas dependências como sala, quarto, cozinha, varanda, garagem, banheiros, etc.

Cada dependência possui suas características e também um objetivo específico para proporcionar uma certa função às pessoas que moram na casa.

Se fôssemos enumerando os relacionamentos das propriedades e funções de cada um desses objetos, teríamos uma enorme árvore hierárquica.

Gostaria que você desse uma olhada na seguinte planta baixa de uma casa e imaginasse a relação hierárquica entre cada objeto:

Imagine a linha preta em volta como sendo o muro. A área verde representa o jardim e a planta interior é a casa com suas dependências e objetos em cada dependência.

Usando uma semântica de notação semelhante à do Visual FoxPro, onde cada objeto contido em outro é separado por um ponto “.”, se fôssemos descrever o que temos na casa faríamos algo como o que se segue:

Muro.Jardim.Casa.Sala.Sofá1.Cor = “Marrom” Muro.Jardim.Casa.Quarto1.Cama.Tipo = “Casal” Muro.Jardim.Grama.Cor = “Verde”

Muito bem, vou parar por aqui a analogia que fiz com a casa. Agora vamos tentar entender como funciona o Modelo de Objetos do Visual FoxPro.

Quando você abre o Visual FoxPro a primeira coisa que temos é uma grande janela contendo várias barras de ferramentas, etc. Essa é a janela principal do Visual FoxPro e no modelo de objetos ela é representada com o nome _Screen.

A partir do Objeto _Screen muitos outros podem ser adicionados, por exemplo formulários, barras de ferramentas, etc, etc.

À medida que vamos adicionando objetos dentro de outro objeto estamos implicitamente criando uma hierarquia entre esses objetos, de forma que para acessar o objeto contido, precisamos especificar também o recipiente (container), ou seja, aquele que contém o objeto contido.

O Visual FoxPro gerencia muito bem a hierarquia dos objetos. Em um nível mais superior como do objeto _Screen, muito raramente precisaremos gerenciá-los.

No entanto, para definir programaticamente propriedades, chamar métodos, disparar eventos, etc, precisamos pelo menos acessar os objetos na hierarquia em nível do formulário em questão.

No nosso caso do formulário de Usuários, onde o nome do mesmo é usuarios poderíamos fazer algo como o seguinte para preencher um valor no campo Nome do usuário:

Usuarios.txtNomeUsuario.Value = “AUTOCOM3” Sendo:

Usuarios -> Nome do formulários

txtNomeUsuario -> Objeto TextBox para o campo nome do usuário

Value -> Propriedade do objeto txtNomeUsuario que irá armazenar o nome do usuário. Vamos ver como isso funciona na prática?

Abra o seu formulário de usuários para modificar e depois clique no botão executar formulário .

Agora, ative a janela de comandos pressionando CTRL+F2. Agora digite na janela de comandos Usuarios.txtNomeUsuario.Value = “AUTOCOM3”

Imagino que você vá colocar o seu nome. ☺ Tudo bem, eu não ligo.

Quando você pressionar ENTER o valor já está alterado no objeto txtNomeUsuario. Viu como é fácil?

Muito bem, agora vamos ver algumas formas relativas de se acessar objetos.

Imagine que num método genérico desenvolvido para ser reaproveitado com vários outros formulários de nomes diferentes você precise acessar alguns botões, métodos, propriedades.

Só que você não saberá qual é o nome do formulário. Por isso ficará inviável usar da forma que fizemos acima.

Para contornar esse problema existe uma palavra chamada THISFORM.

 

Thisform quer dizer este formulário. Ou seja, faz uma referência ao formulário que está executando o código sem se importar qual é o seu nome.

Se você tentar executar o comando: Thisform.txtNomeusuario.Value = “AUTOCOM3”

na janela de comandos você obterá um erro, pois a referência é inválida. Essa referência só será válida quando chamada do próprio formulário e não de outros lugares.

É por isso que no código dos métodos e eventos do nosso formulário está cheio de referência usando thisform. Por exemplo:

Neste caso o código está dizendo para executar o método CoordenaNavegacao, passando o parâmetro “PRIMEIRO” no formulário em questão.

Outra palavra usada para fazer referências relativas é THIS.

This é uma referência para o objeto em questão. Ou seja, quando estamos codificando dentro de um determinado objeto e queremos nos referir a ele próprio então usamos this.

Mais uma palavra para referências relativas:  PARENT.

Imagine que inserimos um objeto container e nele colocamos alguns outros objetos como por exemplo botões de comando.

De repente estamos codificando o evento click do objeto bntBotao1 e precisamos disparar o evento click do bntBotao2. Seria algo mais ou menos assim:

This.Parent.bntBotao2.Click

Aqui estou dizendo assim, acesse o Parent (pai, recipiente, container) no qual estou inserido e então dispare o Click de bntBotao2.

Entendeu a flexibilidade?

A princípio parece complicado, mas à medida que você for codificar perceberá que na prática é mais simples, principalmente se estiver utilizando o recurso de IntelliSense do Visual FoxPro.

No final deste documento você encontra um guia de referência para os comandos e funções utilizados até o momento.

Reaproveitando o código já escrito no formulário USUÁRIOS

Uma técnica já muito conhecida de programadores é a de reaproveitar código escrito para uma determinada rotina em outra. Para isso linguagens estruturadas oferecem as chamadas funções e as bibliotecas de funções.

Em OOP, temos um conceito diferente de reaproveitamento de código. Definimos modelos (templates) que chamamos de classes. A partir de uma classe podemos instanciar uma infinidade de objetos com as mesmas características.

Apesar do conceito ser um pouco vago, você entenderá na prática o que estou tentando dizer. Até o momento definimos um formulário chamado usuarios.scx. Neste formulário adicionamos vários controles do tipo Botão de Comando e dentro de cada botão inserimos um código a ser executado quando do seu pressionamento.

Se fôssemos usar os métodos da linguagem tradicional o que faríamos seria copiar esses controles para um novo formulário e estaria tudo certo.

Aí você pergunta:

─ Funciona dessa forma?

─ Funciona.

─ Então por que não fazer assim?

─ Porque além de você ter o trabalho de copiar tudo cada vez para cada formulário novo, se de repente você encontrasse um erro no código de algum desses botões, você teria que sair corrigindo  o  erro  em  cada  formulário,  sem  contar  que  o  tamanho  do  seu  executável aumentaria bastante pois o código estaria duplicado em cada formulário.

─ Então o que devo fazer?

─ Você deve criar um modelo/template ou simplesmente uma classe. Antes que você pergunte como definir uma classe, vou lhe explicar.

Continua em Desenvolvendo em VFP – Parte 12

Print Friendly, PDF & Email

Sobre o Autor