Aprendendo VisualFoxPro

[hvonk]

Relembrando a primeira mensagem :

Ola galera, estava futucando alguns livros que tenho de FoxPro então pensei porque não compartilha-los como todos da comunidade ja que aqui sempre uns estão ajudando os outros e formamos praticamente uma familia. Então pensei digitaliza-los seria algo demorado uma vez que os livros possuem varias paginas, logo tive a ideia de tornar as coisas mais interativas onde todos pudessem ter o conteudo do livro e estar aprendendo também. Então o que pretendo fazer é digitar o livro inteiro por capitulos e procurarmos juntos entender o seu conteudo, em seguida passamos para o proximo capitulo, como meus dias são corridos, não posso garantir que todos os dias vou estar escrevendo, mas a ideia é essa. Bem espero que todos gostem da ideia, provavelmente este livro niguem mas vai encona-lo para venda, pois é muito antigo, acredito então que vamos nos divertir e aprender bastante nesta jornada. O nome do Livro é Aprendendo Visual Fox Pro. Vou colocar aqui o primeiro capítulo e gostaria que todos participassem tirando dúvidas. Sempre que houver exercícios colocarei a resposta, cabe a pessoa ser honesta consigo mesmo e tentar resolver sem ver a resposta, e uns tirar as duvidas dos outros sempre que surgirem, eu mesmo vou ter muitas no decorrer do livro.

[hvonk]

3.2 PROCEDURE INIT

Vamos aproveitar a própria definição da classe cAlo e acrescentar as
linhas abaixo:

Código:

DEFINE CLASS cAlo AS cHello

mensagem = ‘ALO MUNDO!’
outramensagem = ‘BOM DIA!’

PROCEDURE INIT
r = MESSAGEBOX(‘executada a init’,64,’AVISO’)
ENDPROC

ENDDEFINE

Rodando o programa mex2.prg, vemos que a primeira coisa que aparece é o MESSAGEBOX.

[hugo]

boa hvonk

valeu

ta reputado

[hvonk]

3.3 OBJETO THIS


Quando dentro de uma procedure que esta no arquivo que define uma classe, queremos nos referir a uma propriedade da própria classe (definida nas linhas de cima), temos que usar como prefixo this, como um objeto.
Voltando ao assunto da função INIT:, podemos defini-la com parâmetros. Esses parâmetros devem, é claro, ser usados dentro da definição da procedure para alguma coisa. Podemos então, quando usamos o CREATEOBJECT, passar esses parâmetros. O comando completo fica assim:

Código:

nome-do-objeto = CREATEOBJECT (‘nome-da-classe’, par1, par2 etx.)

O uso desse artifício é muito útil para passarmos valores iniciais para a propriedade de objetos, diferentes dos que foram definidos dentro da criação da classe.
Vamos, por exemplo, alterar novamente a definição da classe cAlo e colocar um parâmetro na procedure Init. O que for colocado nesse parâmetro e tempo de criação de objeto será passado para a propriedade mensagem. Veja abaixo:

Código:

DEFINE CLASS cAlo AS cHello

mensagem = ‘AO MUNDO!’
outra mensagem = ‘BOM DIA!’

PROCEDURE INIT(pmens)
r = MESSAGEBOX (‘Executada a init’,64,’AVISO’)
this.mensagem = pmens
ENDPROC

ENDDEFINE

Se alterarmos o programa mex2.prg, passando um parâmetro no CREATEOBJECT, vemos que será alterado o valor da propriedade mensagem para o objeto oAl. Veja abaixo:

Código:

   SET PROCEDURE TO c:\testesfp\chello ADDITIVE
   SET PROCEDURE TO c:\testesfp\calo ADDITIVE

   oAl = CREATEOBJECT (‘calo’,’mensagem Alterada’)
oHx = CRETEOBJECT (‘cHello’)
oAl.mostra

? oAl.mensagem
? oAl.ouramensagem
? oHx.mensagem

Voltamos a insistir no fato de que na hora do CREATEOBJECT, acontecem muitas coisas alem de ser executada a procedure INIT. Todas as propriedades das classes ancestrais (Ate a básica do VFP) são criadas na memória. Todos os métodos de uma classe também terão de estar carregados na memória.
Podemos dizer que existe uma função construtora implícita e uma função construtora explicita (que seria o INIT) que são executadas quando se cria um objeto. Nós so temos acesso a essa parte explicita, o que nos levaria a dizer que só podemos fazer um override de complementação da função construtora.
Devido a isso a existência de um objeto consome memori; as vezes muita. Sempre que não formos mais utilizar um objeto, é interessante tira-lo da memória com o comando RELEASE que tem a sintaxe:

RELEASE objeto

Quando executamos esse comando, uma procedure chamada DESTROY é também executada se foi definida na criação da classe. Podemos como no caso da INIT, usá-la para algumas coisas.
Podemos dizer então que, semelhantemente a construtora, existiria uma função destruidora implícita ( que libera a memória etc.) e uma função destruidora explicita que se chama DESTROY.
Como exercício vamos colocar uma procedure DESTROY na definição da classe cAlo, projetando outro MESSAGEBOX. E vamos dar release no objeto oAl, no FM do programa mex2.
A nova definição da classe e o novo programa aparecem abaixo:

Código:

DEFINE CLASS cAlo AS cHello

mensagem = ‘ALO MUNDO!’
outramensagem = ‘BOM DIA!’

PROCEDURE INIT (pmens)
r = MESSAGEBOX(‘Executada a INIT’,64,’AVISO’)
this.messagem = pmens
ENDPROC

PROCEDURE DESTROY
r = MESSAGEBOX (‘Executada a;DESTROY’,64,’AVISO’)
ENDPROC

ENDDEFINE

Código:

SET PROCEDURE c:\testesfp\chello ADDITIVE
SET PROCEDURE c:\testefp\calo ADDITIVE

oAl = CREATEOBJECT(‘calo’,’Mensagem Alterada’)
oHx = CREATEOBJECT(‘cHello)
oAl.mostra

? oAl.mensagem
?oAl.outramensagem
?oHx.mensagem
RELEASE oAl

O programador deve se preocupar com o fato de que um INIT ou DESTROY numa classe derivada, mata a mesma função da classe ancestral. Se necessário, pode-se fazer um override de complementação, colocando a função da ancetral dentro da outra.


3.4 EVENTOS

Essas procedures que são disparadas indiretamente como a INIT a DESTROY são chamadas de eventos. Vamos ver que existem vários eventos definidos no VFP. O mais usado deles sem duvida é o que é disparado quando se da um clique com o botão esquerdo do mouse sobre um objeto de uma classe com interface gráfica, por exemplo: um Botão. Essa procedure/evento tem o nome de click. Mas estamos nos antecipando. Vamos falar de classes com interface gráfica no próximo capitulo. Aguarde.

[hvonk]

Capítulo 4

Classes Úteis

Podemos colocar numa classe, qualquer conjunto de métodos e propriedades, mas o bom senso e os métodos de OOP recomendam que cada classe deve se referir a entidades significativas ou dos negócios da empresa ou do próprio sistema de informática. As classes que criamos até agora, por exemplo, só tem valor didático, pois não estão ligadas a nenhuma dessas coisas.
As classes podem se referir a objetos de negocio como produto, cliente etc. Ou a objetos de informática como forms (que poderíamos traduzir por: quadro, janela etc. Mas preferimos deixar no original), listboxes etc.
Hoje, entre os teóricos da OOP se discute o que fazer com os serviços de negocio (uma compra, uma importação etc), e os serviços de informática: se poderamos considera-los como objetos. Na realidade, o melhor é você deixar essas firulas teóricas um pouco de lado e sempre reunir em uma classe um conjunto de métodos e propriedades interessantes e que tenham alguma relação entre si. Procure colocar numa classe, algo que poderá ser reusado. Não tem sentido encapsular uma função que deve aparecer apenas uma vez num programa de uma aplicação.
O programa de aplicação (que estamos chamando de main nos exercícios) tem as suas próprias funções e variáveis e usa objetos (métodos e propriedades) que foram encapsulados para reuso.

4.1 Classes Gráficas

No VFP, temos um conjunto de aproximadamente 30 classes que se referem principalmente a objetos de informática. Quase todas são classes gráficas, isso significando que, quando um objeto delas é criado, sua função construtora implícita faz com que algo seja desenhado na tela do monitor. A classe Form é sem duvida a mais útil delas, no ambiente Windows.
Como já dissemos, uma classe é construída de propriedades e métodos. A classe Form, por exemplo, tem quase oitenta propriedades. Se você quiser estudar cada uma delas, use o Help do VFP (entretanto achamos que não vale a pena fazer isso- você vai aprendendo com a pratica). Vamos citar algumas delas que vamos usar no próximo exercício:

BackColor – o valor dela define a cor do form. Damosabaixo os principais valores:

Código:


16777215 = branco
12632256 = cinza
255 = vermelho
65535 = amarelo
32768 = verde
16711680 = azul

Esses números malucos surgem como retorno de uma função que combina os três números que dão a intensidade dos três canhoes de cores que todo monitor tem: R(red), G(Green), B(blue), numa escala de 0 a 255. Essa função especifica-se como:

Código:

RGB (parred, pargreen, parblue)

Podemos usar na propriedade, o numero diretamente ou colocá-la recebendo o retorno da função. Nesse caso, temos para as cores mais usadas os parâmetros:

Código:

255,255,255 branco
192,192,192 cinza
255,0,0 vermelho
255,255,0 amarelo
0,255,255 verde
0,0,255 azul
O valor default é o da cor branca.

SelectMode – o valor dela especifica a escala a ser usada para todos os valores de propriedades que definem tamanho na tela do monitor:

3 - valor para significar que a unidade de medida é o pixel.
0 – significa que será usada como unidade uma coisa chamada foxel. A invenção do foxel é um truque esperto para facilitar a colocação de textos nos forms. A altura de um foxel é a altura do caractere da fonte que estiver sendo usada. A largura é a média dele.

O valor default é o do foxel.

Left e Top – são duas propriedades que dão as coordenadas do afastamento da extremidade superior esquerda do form.

Os valores default são 0 e 0.

Width e Height – são duas proppriedades que dão a largura e a altura do form.

Os valores default são 62,50 e 15,63 em foxels considerando a fonte default que é arial/10.

Atenção: as medidas não incluem as bordas e barras do form.

A classe form tem também uns trinta métodos. Vamos so falar de um muito importante:

Show – quando executado, faz com que o form ciado seja projetado (aberto) na tela.

Importante: quando usamos o botão do canto direito (no Windows) dum form para fecha-lo, é dado, por default m comando que vai fechar todos os dorms que tiverem sido criados no programa. Isso foi definido assim na função destruidora implícita definida pelo pesoal da Microsoft. No nosso caso, isso não tem importância. Caso fosse necessário fechar um form por vez, teríamos de pensar numa solução alternativa.

4.2 O Loop dos Eventos

Quando projetamos um form na tela do monitor, é preciso que ele fique disponível para receber cliques do mouse e outras coisas que disparam eventos (alias essas coisas são também as vezes chamadas de eventos), principalmente o que vai fechar o form.
Para que se crie essa disponibilidade dispara-se um loop no Windows através do comando: READ EVENTS, no programa que cria o form.
É preciso muito cuidado para que, quando se fecha o form, esse loop se encerre. Para isso colocamos na procedure DESTROY ( na definição da classe) o comando: CLEAR EVENTS.
Se seu programa entrar em loop, selecione Program/cancel na barra de menu do VFP.

4.3 Uma classe derivada de form

Digamos que queremos criar uma classe derivada da classe form e que tenha como característica o fato de que, quando criarmos um objeto dela, poderemos determinar seu tamanho e localização na tela em pixels. A cor desses objetos será sempre cinza. Vamos chamar essa classe de cNofo (pensando em nosso form). Gostamos de usar poucas letras para evitar o trabalho de digitação. Se você se atrapalha com isso, crie seu próprio esquema de trabalho depois de terminar de ler o livro – evite alterar os exercícios.
O programa que cria classe (cnofo.prg) esta abaixo:

Código:

DEFINE CLASS cNofo AS Form

ScaleMode = 3
BackColor = RGB(192,192,192)

PROCEDURE INIT (PL,PT,pW,pH)
this.Left = pL
this.Top = pT
this.Width = pW
this.Height = pH

ENDPROC

PROCEDURE DESTROY
CLEAR EVENTS
ENDPROC

ENDDEFINE

Vamos escrever um programa main (mex3.prg) em que criamos quarto objetos, cada um emu ma posição diferente da tela. Ele aparece abaixo:

Código:

SE PROCEDURE TO c:\testesfp\cnofo ADDITIVE

oNofo001 = CREATEOBJECT (“cNofo”,0,0,100,100)
oNofo002 = CREATEOBJECT (“cNofo”,110,0,100,100)
oNofo003 = CREATEOBJECT (“cNofo”,220,0,100,100)
oNofo004 = CREATEOBJECT (“cNofo”,0,140,100,100)
oNofo001.Show
oNofo002.Show
oNofo003.Show
oNofo004.Show

READ EVENTS

[hugo]

muito bom

[hvonk]

4.4 Uma classe derivada de form

Duas outras classe importantes tornadas disponível no VFP são a CommandButton e a TextBox.
A classe TextBox serve para criar objetos gráficos cuja utilidade maior e conter valores que podem vir de variáveis isoladas ou serem propriedades de um objeto. O valor deve ser colocado numa propriedade do objeto chamada value para aparecer na tela. Ela aceita qualquer tipo de valor: caractere, numérico etc.
Como muitas outras classes, essa também tem definidas as propriedades: Left, Top, Width, Height e Backcolor. No total a classe TextBox tem quase 60 propriedades e 15 métodos e um objeto dela pode disparar mais de 20 eventos diferentes.
A classe CommandButton define os botões que tem um evento muito usado que é o click. Quando clicamos com o botão esquerdo do mouse sobre a representação gráfica de um objeto de uma subclasse dela, é disparada uma procedure que normalmente foi definida na criação da subclasse. Isso faz com que na maior parte das vezes, a subclasse tenha apenas um objeto incluído em um dado form. Vamos tratar de objetos que contem outros, logo mais abaixo.
A classe CommandButton possui as propriedades Left, Top, Width e Height. São quase 40 propriedades, sendo uma das mais empregadas a Caption, que é onde se coloca o titulo que vai no botão.
Uma característica importante dessas duas classes (e suas derivadas) é que seus objetos tem que ser criados dentro de algum outro objeto (do tipo chamado container – um da classe Form, por exemplo). Isso pode ser feio no programa main. Primeiro se cria um objeto container e depois se criam os outros. A função que cria esses objetos contidos tem a seguinte sintaxe:

Objeto-container.ADDOBJECT (‘nome-do-objeto’,’classe’,pini1, pini2 etc)

Outra característica importante dessas duas classes é que possuem um propriedade chamada Visible que torna um objeto dela visível ou não. O default é .F. (de falso) de onde é preciso, no programa main, depois de criado o objeto, passar essa propriedade para .T. Isso pode ser feito também na definição da classe derivada.
Vamos fazer um pequeno exercício em que criamos uma classe cNotx e outra cNoBt em dois arquivos (cnotx.prg e cnot.prg) depois fazemos um progama main (mex4.prg) em que criamos primeiro um objeto daquela classe cNofo e depois vários objetos dessas novas classes. Apresentamos abaixo as lista com os programas.

Código:

DEFINE CLASS cNotx AS TextBox

Visible = .T.

PROCEDURE INIT(pL,PT,Pv)
this.Left = pL
this.Top = pT
this.Value =  pV

ENDPROC

ENDDEFINE


Código:

DEFINE CLASS cNobt AS CommandButton

Caption = ‘Mensagem’
Visible = .T.

PROCEDURE INIT (pL,pT)
this.Left = pL
this.Top = pT

ENDPROC

PROCEDURE CLICK
R = MESSAGEBOX (‘Disparada pelo;
CLICK’,64,’AVISO’)

ENDPROC

ENDDEFINE


Código:

SET PROCEDURE TO
C:\testesfp\cnofo, C:\testesfp\cnotx;
C:\testesfp\cnobt ADDITIVE

oNofo005 = CREATEOBJECT(‘cNofo’,0,0,300,300)
oNofo05.ADDOBJECT(‘oNotx001’,’cNotx’,0,0,’caracteres’)
oNofo005.ADDOBJECT(‘oNotx002’,’cNotx’,110,0,999)
oNofo005.ADDOBJECT(‘0Nobt001’,’cNobt’,0,50)
oNofo005.Caption = ‘EX4’
oNofo005.Show

READ EVENTS


Algumas coisas devem ser ressaltadas:
Todos os paths das definições de classe ficam numa só linha de código.
Para dividir uma linha de código em duas linhas do editor usa-se ponto e virgula.
Todo form tem um titulo que fica numa sua propriedade chamada Caption. Nós a mudamos para EX4.
Execute o programa main, e clicamos em seguida no botão, para aparecer o MessageBox. Poderíamos ter aumentado um pouco o tamanho do botão. Nos deixamos o tamanho default.
Vamos ver mas a frente que o VFP tem uma estrutura que nos facilita a montagem de forms com vários controls. Toda essa programação que fizemos poderia ter sido feita pelo VFP a partir de definições nossas em tempo de design. Estamos contruindo esses programas mais para passar os conceitos básicos da OOP.

[hvonk]

Capítulo 5

Arquivamento de Objetos


Um dos pontos fracos dos aplicativos de desenvolvimento de aplicações que usam orientação a objetos hoje em dia, é o sistema de arquivamento de objetos. Na realidade, com exceção de alguns produtos como o Argos, da empresa Versant Object Tecnology e uns outros poucos também desconhecidos aqui no Brasil, essas ferramentas não vem com um banco de dados orientado a objetos.
De fato elas não são bem linguagens para OOP mas linguagens hibridas que usam parte da OOP junto com muita coisa de banco de dados relacionais, e mesmo programação clássica. Por isso fica muito difícil, pricipalmente para o programador pouco experiente, conseguir aprender em profundidade a lógica por trás de tudo o que é feito.
Vamos tentar nesse livro, conciliar as coisas dentro do possível e, se você não aceitar bem nossas explicações, saiba que ate certo ponto você esta com a razão: E muito difícil mesmo ligar essas coisas.

5.1 Objetos de Negócios

No ultimo capitulo criamos, vários objetos que poderíamos chamar de objetos de informática; forms, textboxes e botões. Na OOP aplicada numa empresa, no entanto, temos que tratar também dos chamados objetos de negocio: cliente, produtos, empregados, notas fiscais etc.
A descoberta das classes existentes numa empresa é uma tarefa complicada. No fim das contas, o que estamos fazendo é reunir definições de dados e rotinas de programação de tal maneira que possam ser reusadas em varias aplicações. Essas coisas são reunidas em conjuntos quqe tem alguma característica comum: são relacionadas com produtos que a empresa fabrica, são relacionadas com os empregados da empresa etc.
Não existe nenhuma formula mágica que diga que deva se criar ou não determinada classe de uma determinada forma. Algumas pistas podem ser encontradas em livros que tratam de métodos de analise de sistema usando orientação a objeto. Na maioria das vezes, no entanto, o que vai prevalecer é o bom senso do analista. Alias isso já acontecia na definição dos bancos de dados relacionais. Apesar de todas as teorias formas normas etc. na hora da realidade muita coisa tinha que ser ajeitada mesmo colocando alguns puristas teóricos.
Umas das coisas que se discute muito hoje, como alias já comentamos, é se serviço de negocio (uma venda, por exemplo) seria ou não um objeto. Essas discussões acontecem em revistas técnicas especializadas e podemos recomendar pelo menos uma: OBJECT MAGAZINE, que pode ser encontrada em bancas de São Paulo. (A publicação é da SIGS PUBLICATION INC., 236 West 26th Streeet, Suíte 75W, New York NY – email: subscriptions@sigs.com).


5.2 Objetos de Negócios


Nossos amigos da Microsoft desculpe-nos, mas vamos mostrar aqui algumas limitações do FoxPro relativas a OOP. Isso não significa que ele não seja um bom produto. Na realidade, o VFP tenta reunir o melhor dos três mundos: OOP, o SQL e a programação clássica. Isso e uma boa abordagem, mas pode confundir muito a cabeça, principalmente, de programadores iniciantes.
Vamos dar um exemplo de como se trabalha com OOP (apesar das limitações do VFP). Suponhamos que você seja o sindico de um condomínio tipo Melrose Place (seriado que passa nas tardes de domingo na GLOBO) com poucos moradores e é fanático por OOP. Digamos que você vai querer usar o FoxPro para fazer um pequeno sistema que controla o deposito do condomínio, onde são guardadas algumas coisas que os moradores não querem em seus apartamentos (uma televisão velha, por exemplo) mas não querem se desfazer.
Podemos definir dois tipos de objetos de negocio para o sistema: morador e material (as tais coisas). Você poderia pensar em outros objetos: estante, apartamento etc. Como dissemos ai em cima, o bom senso do analistaqprogramador é que vai determinar os objetos que serão definidos como classes na empresa num determinado momento. Nos optamos por aqueles dois. Se quisermos depois guardar muitas informações sobre um apartamento (se decidíssemos fazer um sistema de manutenção, por exemplo), este poderia se transformar em mais um objeto de negocio e mais uma classe seria criada na empresa (digo, no condominio).
Para cada objeto, vamos pensar nas propriedades que serão definidas na classe. Mesmo que nem todas sejam usadas no sistema temos em mente no momento, podemos defini-la se pensamos em usa-las a curto prazo. No futuro, isso pode ser alterado para mais ou para menos. Isso também e uma questão de bom senso. Você não deve colocar todas as propriedades possíveis de um objeto na classe. Vamos começar as definições de classes abaixo que seria o programa cmora.pg. Vamos chamar a classe de cMora.

[Marcos Guedes]

Acompanhando e reputando...

[Julio]

Parabens pela iniciativa.


Abs

julio