MANUAL DO DESENVOLVEDOR ERP LINX

MANUAL DO

DESENVOLVEDOR LINX

OBS: ESTA VERSÃO É ANTIGA, MAIS AINDA É VALIDA PARA A MAIORIA DAS CUSTOMIZAÇÕES, QQ DUVIDA É SÓ DEIXAR UM COMENTÁRIO.

REQUISITOS BASICOS:

Conhecimentos necessários para entrar no ambiente LINX de DESENVOLVIMENTO

-Filosofia Cliente/Servidor

Comandos SQL

                               Select / Insert / Update / Delete

                               Base de Dados relacional

                               Chaves Primarias/Estrangeiras

                               Link entre tabelas (JOIN)

                               Transação e Rollback

-Visual Foxpro: Manipulando Dados

Views remotas Visual Fox

               Inserção e Atualização de Dados

               Lock otimista

               Definições de chaves para atualização e deleção

                               Views para consulta (Sum/Count etc...)

-Orientação Objeto

                Classes

                Eventos

                Propriedades

-VisualFox: Objetos Básicos

                Form

                Formset

                Dataenviroment

                Controls/Grids

TOOLBAR DO VISUAL LINX

 Versão Antiga

Nova Versão

TABELA DE EVENTOS DA CLASSE LINX

MÉTODOS DESENHISTA

Todos os botões da toolbar linx chamam métodos/eventos da classe FORMSET da Linx, cada um destes métodos executa uma operação muito conhecida de todos nos, como Incluir um registro, Salvar etc... . Estes métodos são os métodos base da classe como por exemplo o L_EXCLUI, L_INCLUI ou L_SALVA isto significa que a classe linx esta preparada para fazer um inclusão/exclusão ou alteração em qualquer tabela da base de dados através das views remotas do Fox porém normalmente não é por ai que acabam as necessidades das nossas forms. São precisos cálculos, verificações etc.. para que você programador não tenha que se preocupar com parâmetros ou seqüências de um métodos/evento Linx foram criados os métodos Desenhista.

Os métodos desenhista, são os locais indicados para o desenhista (desenvolvedor) escrever o seu código Fox.  A tabela seguinte descreve a aplicação dos principais métodos.  Os botões mencionados na tabela se referem aos botões da ToolBar do Visual Linx.

Exemplos

Método	Aplicação
L_Desenhista_Inclui_apos	·       Chamado entre o pressionamento do botão INCLUIR e o refresh da form lterar.  É adequado escrever nele o código para setar defaults nas view’s locais !
L_Desenhista_Antes_Salva	·       Chamado entre o pressionamento do botão SALVAR e a gravação efetiva nas tabelas do banco de dados.  O código escrito neste método é útil para preparar chaves compostas, realizar validação das informações a serem gravadas, etc.  Deve retornar .T. permitindo a gravação e .F. impedindo o prosseguimento do salvamento.
L_Desenhista_procura_antes	·       Chamado entre o pressionamento do botão PESQUISAR  e a execução do Query/Pesquisa que será enviado a base de dados.  É adequado para colocar filtros especiais nas pesquisas
L_Desenhista_procura	·         Chamado após o banco de dados enviar o resultado da Query/Pesquisa para a maquina local e antes do refresh  É adequado para somar informações para apresenta-las junto com os dados recebidos.
L_trigger_antes	·         Chamado durante o salvamento dos dados, porem diferente do L_desenhista_antes_salva este método é chamado dentro da transação de salvamento, ou seja aquilo que for enviado a base de dados , caso seja dado o rollback vai voltar atrás !

9. Mensagens para Implementação de código na TRANSAÇÃO:

Mensagens do FORMSET:

         L_DESENHISTA_ALTERA

         - Mensagem disparada após ser pressionado o botão de Alteração, antes do refresh.

Ex.: Mensagem pode ser usada para desabilitar algum campo ou botão que fique sob seu controle e que não possa ser alterado em uma alteração

         L_DESENHISTA_APOS_SALVA

         - Mensagem disparada após a baixa dos dados para uma Tabela Pai

         L_DESENHISTA_FILHAS_EXCLUI_ANTES

                - Após a exclusão dos dados da Tabela Pai esta mensagem é disparada antes de começar a exclusão da Tabela Filha

        

         L_DESENHISTA_FILHAS_EXCLUI_APOS

- Após a exclusão dos dados da Tabela Pai esta mensagem é disparada após a exclusão da Tabela Filha

         L_DESENHISTA_FILHAS_INCLUI_ANTES

- Após dar um APPEND BLANK( ) na Tabela Pai, esta mensagem é disparada antes de começar a inclusão da Tabela Filha

         L_DESENHISTA_FILHAS_INCLUI_APOS

- Após dar um APPEND BLANK( ) na Tabela Pai e na Tabela Filha, esta mensagem é disparada

         Ex.: Mensagem usada para setar os PARAMETROS nas Tabelas Filhas

         L_DESENHISTA_INCLUI

         - Mensagem disparada após ser pressionado o botão de Inclusão

         Ex.: Mensagem usada para setar os PARAMETROS na Tabela Pai

         L_DESENHISTA_PRINT_ANTES

         - Mensagem disparada antes de começar a Impressão

         L_DESENHISTA_PRINT_APOS

         - Mensagem disparada após a Impressão

         L_DESENHISTA_REFRESH

         - Mensagem disparada quando ocorre uma mudança de estado dos botões da ToolBar

Ex.: Mensagem em que se pode colocar o Recalculo de campos definidos por variáveis,              uma vez que estes campos não são guardados em nenhuma Tabela

         L_DESENHISTA_RECALCULO

                - Mensagem disparada após ser executado o Método VALID( ) do Objeto

Ex.: Mensagem em que se pode colocar os envios de Recálculos para outros campos da Tabela, ou realizar alguma operação no retorno da Validação

TERMINOLOGIA LINX

Além da terminologia normal da informática (técnicas, linguagens, bancos de dados, etc) alguns termos utilizados pela empresa no desenvolvimento de sistemas são:

Termo	Significado
Banco	·       Banco de dados.  Quase sempre se refere a um banco de dados do MS-SqlServer. “Levantar o banco Desenv”, por exemplo, quer dizer colocar no ar o banco de dados “Desenv”
Builder	·       Construtor de objetos Linx.  Semelhante aos builders do Fox, é um programa-ferramenta de desenvolvimento “\Linx_Sql\Desenv\FormTool\Lx_Build.scx” que deve ser executado como ponto de partida na criação de novas telas com controles de entrada de dados.  O builder colocará nos objetos container (form, page, grid etc) controles derivados diretamente das classes padrões da Linx.  Ao contrário dos builders do Fox, o builder da Linx não deve ser usado, ao menos por enquanto, para modificar controles previamente criados  em um container
Case	·       Modelo de dados.  Além de referir a uma ferramenta case, como o ERwin, muitas vezes é usado para designar o produto da ferramenta; em “imprime o case pra mim”, case é a folha impressa com o modelo de dados gerado pelo ERwin
ComboBox Valida	·       Uma combo, da classe Lx_ComboBox, montada a partir de uma “Tabela Valida”, para a escolha de itens específicos a serem entrados
Desenhista	·       Designer, projetista.  É o programador que desenha uma tela.  Diversos métodos padrões das classes Linx, que levam desenhista no seu nome, devem ser usados no lugar dos métodos originais do Fox.  Ex.: em vez de escrever código dentro do método INIT de um formset, deve-se fazê-lo dentro do método (ou mensagem) padrão L_Desenhista_Init desse formset
Desenv	·       Banco de dados SqlServer utilizado para testes durante o desenvolvimento do Visual Linx. Também é o diretório de desenvolvimento, em “\Linx_Sql\Desenv”
Form Tipo Consulta	·       Form que não vai alterar dados, apenas consultá-los.  Define-se um form tipo consulta através da propriedade “p_Formset_Consulta=.T.” do formset
Form Tipo Table	·       Form para manutenção de uma única tabela (não há tabela pai nem filha).  Os controles são colocados no corpo do form.  Define-se um form tipo table através da propriedade “p_Formset_Table=.T.” de seu formset
Levantar/Derrubar o Banco	·       Colocar/Tirar do ar um banco de dados
Linx_102	·       Programa principal do Visual Linx.  O programa inicial do Visual Linx que está em “\Linx_Sql\Linx\Prg\Linx_102.Prg”, e é recomendável executá-lo antes de qualquer desenvolvimento (telas, relatórios, etc), pois sua execução atualiza o ambiente de desenvolvimento, como, por exemplo, refazer a cópia do “C:\Temp\Lx_Temp.Dbc” banco temporário de views
Lx_Class	·       Biblioteca de classes padrões Linx.  Em “\Linx_Sql\Desenv\Lib\Lx_Class.Vcx”
Lx_Temp	·       Banco de dados temporário de views.  Normalmente gravado em “C:\Temp\Lx_Temp.dbc”, é uma cópia do banco oficial de views “ViewLinx”, feita sempre que se executa o Visual Linx “Linx_102”.  A princípio, views remotas, views locais, conexões etc, utilizadas nos projetos do Visual Linx devem ser referenciadas a partir desse banco temporário
Lx_Tools	·       Biblioteca de classes padrões Linx.  Em “\Linx_Sql\Desenv\Lib\Lx_Tools.Vcx”
LxProce	·       Arquivo de procedures e funções.  “Quem está usando a proce?” quer dizer quem está com o arquivo “\Linx_Sql\Desenv\FormTool\LxProce.Prg” aberto para edição.  Na verdade, procedures e funções, quando necessários, são criados dentro de uma tabela “\Linx_Sql\Desenv\FormTool\LxProce.Dbf” que está dentro de um banco de dados “\Linx_Sql\Desenv\FormTool\Lx_Tools.Dbc”.  Depois de alterada a tabela com a nova função, deve-se rodar o programa-ferramenta de desenvolvimento “\Linx_Sql\Desenv\FormTool\Lx_CrPro.Prg”, que criará automaticamente o arquivo “LxProce” de procedures e funções
Mensagem	·       Chamada de um método.  Às vezes, se refere aos métodos “desenhista”
Módulo	·       Componente significante do Visual Linx, praticamente independente.  Os módulos são dirigidos às áreas administrativas específicas como Compras, Produção, Faturamento, Vendas, Clientes etc.  No tópico seguinte se encontra a tabela dos módulos do Visual Linx com suas respectivas descrições e nomes.  Os módulos devem ser cadastrados no próprio Visual Linx
Navegação	·       Caminho de acesso a uma “transação” do Visual Linx.  Uma navegação passa por um a) “Módulo” do Visual Linx, por um b) menu do módulo e por um c) item de menu.  Assim: módulo/menu/item.  Ex.: A navegação “COMPRA 3.2” (módulo Compra, menu 3, item 2) leva à transação “Compras de Consumíveis/Imobilizáveis”, cadastrada no Visual Linx com o código “Compras_003”.   Navegações e transações devem ser cadastradas no próprio Visual Linx
Parâmetro	·       Dado passado para a transação.  Da mesma forma que “transação” e “navegação”, os parâmetros são cadastrados no próprio Visual Linx, e vinculados a uma transação (como cadastramento de clientes, por exemplo).  Quando essa transação é executada, seu formset recebe esses parâmetros em forma de propriedades, que ficam disponíveis para uso em tempo de execução
Roubar Mensagem	·       Override de eventos e métodos.  É a sobreposição de um evento ou método de uma classe pai por um evento ou método de um objeto filho daquela classe.  Ex.: escrever código no controle “LxBotao1.Init” impede a execução do código de seu pai “LxBotao.Init”, a menos que dentro do filho “LxBotao1.Init” use-se o operador  de resolução de escopo “::” para executar o evento do pai: “LxBotao::Init”.  A Linx utiliza os métodos “desenhista” para evitar problemas ao “roubar mensagem”
Tabela Valida	·       Uma tabela do banco de dados (não é view nem cursor) específica para alimentar uma “ComboBox Valida” ou uma “TextBox Valida” para validação de dados - verificar existência e limitar a entrada de dados
Text Box Valida	·       Um text box, da classe Lx_TextBox_Valida, que responde ao clique direito do mouse, apresentando uma janela com os dados de uma “Tabela Valida” específica, para serem escolhidos
Transação	·       Um recurso disponível no Visual Linx.  Além da conversa entre o client e o server, “transação” é uma atividade executada no Visual Linx; como Cadastramento de Clientes, Entrada de Produtos Acabados, etc.  Chega-se à transação através da “navegação” nos “módulos”, menus e itens de menu. As transação e sua navegação devem ser cadastradas, no próprio Visual Linx, na navegação “UTILIT 1.1”
V_Remota	·       Banco de dados de criação de views.  Em geral, views locais, views remotas, conexões para bancos de dados etc, devem ser criadas no banco de dados “\Linx_Sql\Linx\View\V_Remota.Dbc” de criação de views.  Uma vez alterado o “V_Remota” deve-se rodar o programa-ferramenta “Visoes”, que fará uma cópia desse banco de criação para o banco original de views “ViewLinx”
View  Pai	·       Criada sobre uma(s) tabela(s) pai, é a view que relaciona abaixo de si uma ou mais “Views Filhas”
View Filha	·       Criada sobre uma(s) tabela(s) filha, é a view que está relacionada a uma “View Pai”
ViewLinx	·       Banco de dados original de views.  O “\Linx_Sql\Linx\View\ViewLinx.Dbc” está sempre fechado e disponível.  É gerado pelo “Visoes” e copioado pelo “Linx_102” para o banco temporário “Lx_Temp” de views
Visão	·       View.  Uma view (Select Sql) que gera um cursor no Fox
Visões	·       Copiador de views.  Programa-ferramenta de desenvolvimento, o “\Linx_Sql\Desenv\FormTool\Visoes.Prg” copia o banco de criação de views “V_Remota” para o banco original de views “ViewLinx”.  O “Visoes” é o único que ABRE o “ViewLinx” em tempo de desenvolvimento; desse modo o banco original está sempre fechado e disponível

A terminologia permite uma certa liberdade de expressão.  Os elementos de desenvolvimento ora são referenciados no plural ora no singular, ora no feminino ora no masculino.  Pode usar “o form” ou “a form”, mesmo porque “form” poderia ser traduzido como “formA” ou “formuláriO”.  E assim por diante…

MÓDULOS DO VISUAL LINX

Cada módulo coloca na barra de menus, seu próprio menu que, através de seus itens, dá “navegação” para as “transações” do Visual Linx.

    módulos do Visual Linx em \Linx_Sql\Linx\Menu\LxGeral.Scx

O nome de cada módulo está na tabela seguinte:

Módulo	Nome	Módulo	Nome
Utilitários	UTILIT	Filiais	FILIAL
Fornecedores	FORNEC	Representantes de Vendas	REPRES
Clientes	CLIENT	Produtos Acabados	PRO_AC
Matérias-Primas	MATPRI	Compras	COMPRA
Entradas de Notas Fiscais	ENTRAD	Estoque de Matérias-Primas	ESTMP
Estoque Produtos Acabados	ESTPA	Produção	PROD
Contas a Receber	RECEB	Contas a Pagar	PAGAR
Faturamento	FAT	Expedição	EXPED
Gerencial	GEREN	Lojas	LOJAS
Vendas	VENDA	Fichas Técnicas	FICHTE
Produtividade	PRODUT	Contas Correntes	CC

ESQUEMA LINX DE NOMENCLATURA

A nomeação dos elementos de desenvolvimento Linx (arquivos, classes, objetos, etc.) deve seguir, sempre que possível, a seguinte recomendação:

Elemento	Recomendação
Arquivos .Frx	·       Os arquivos de definição de relatórios devem ser salvos no formato “Lyyyzzza.Frx”, onde “yyy” é um número seqüencial de módulo, “zzz” é um número seqüencial de tela naquele módulo, e “a” é uma letra de A-Z (ex: L095009A.Frx).  Nesse caso, temos o primeiro (A) relatório da nona tela (009) do módulo de contas a receber (095).  Na verdade esses números são gerados pelo Visual Linx e os relatórios gravados automaticamente; pois a criação de relatórios é feita, quase sempre, dentro do próprio Visual Linx.  Os arquivos .Frx devem ser gravados, em princípio, no diretório “\Linx_Sql\Linx\Report\Linx”
Arquivos .Pjx	·       Há um projeto para cada membro da equipe de desenvolvimento do Visual Linx, evitando problemas de compartilhamento; tais projetos devem ser gravados em “\Linx_Sql\Desenv”. Arquivos de projeto (.Pjx) são salvos com nomes na forma “Lx_apelido.Pjx”;  apelido é o nome abreviado do desenvolvedor (ex: Lx_Alex.Pjx é o projeto sobre o qual o Alexandre trabalha)
Arquivos .Scx	·       Os arquivos de definição de telas (normalmente um formset) devem ser salvos com nomes que obedecem o formato “Lxyyyzzz.Scx”, onde “yyy” é um número seqüencial de módulo, e “zzz” é um número seqüencial de tela naquele módulo (ex: Lx095009.Scx).  Nesse caso, trata-se da nona (009) tela do módulo de contas a receber (095).  Esses números de módulo e tela serão, na maioria das vezes, indicados por quem solicitar a confecção da nova tela.  Os arquivos .Scx devem ser gravados, em princípio, no diretório “\Linx_Sql\Linx\Form\Desenv”
Arquivos .Vcx	·       Os arquivos de bibliotecas de classes visuais são salvos como “Lx_nome.Vcx”, onde nome é o nome da biblioteca (ex: Lx_Class.Vcx e Lx_Tools.Vcx)
Classe	·       As classes padrões da Linx, que normalmente estão nas bibliotecas “Lx_Class” e “Lx_Tools”, têm seus nomes na forma “Lx_nomeclasse”, em que nomeclasse é o nome da classe padrão
Cursor	·       Objetos cursores (execução da view/Select); para definir sua propriedade NAME deve-se acrescentar o prefixo “cur” ao nome da view que vai gerar o cursor (ex: cur_v_Bancos_LayOut_01 será um cursor criado com a segunda view da tabela Bancos_LayOut)
Form	·       A propriedade NAME dos forms deve permanecer na forma “Lx_Form1” derivada de “Lx_Form” sua classe pai.  PageFrames, Pages e Grids, às vezes, também ficam com seus nomes na forma derivada
FormSet	·       Para dar nome a um formset (propriedade NAME), deve-se observar antes o nome da transação que dará acesso a esse formset; a propriedade NAME recebe o nome dessa transação.  O arquivo “Lx095009.Scx”, por exemplo, contém um formset de nome “Bancos_003”, porque a transação “Bancos_003” oferece a navegação (caminho) para “Lx095009.Scx” (Captação de Arquivo Retorno de Contas a Receber)
Método	·       Semelhante às propriedades, os métodos criados nas classes começam com “L_” (ex: l_Recalcula); os métodos criados nos objetos dessas classes começam com “LX_” (ex: lx_ContaProduto)
Objeto	·       Há uma certa liberdade no modo de nomear (propriedade NAME) os controles derivados das classes padrões Linx, porém costuma-se aplicar o formato “tipo_nome”.  O tipo procura lembrar a família do objeto: combo (cmb), textbox (tx ou tv), coluna (col), checkbox (chk ou ck), cursor (cur) etc.  O nome é um identificador para o objeto: valor, razao_social, cep, etc.  Ex: cmb_Unidade pode ser um combo de unidades de medida (peça, kg, metro, etc).  Alguns controles permanecem com o nome derivado da classe pai, com “Lx_Grid_Filha1”, “Lx_Form1”, “Lx_Image1”, etc
Parâmetro	·       Os parâmetros se transformam em propriedades do formset executado, e têm os nomes na forma “pp_NomeParametro”, onde NomeParametro é como o parâmetro foi previamente cadastrado no Visual Linx na tabela Transacoes_Param do banco de dados
Propriedade	·       Durante a CRIAÇÃO (definição) de classes padrões do Visual Linx, as propriedades nelas criadas devem ser nomeadas começando-se por “P_” (ex: p_ArquivoTxt); durante a UTILIZAÇÃO (derivação) de objetos daquelas classes, as propriedades criadas (acrescentadas) devem começar por “PX_” (ex: px_ValDesconto).
Tabela	·       Criadas pelo DBA nos bancos do SqlServer, com a ferramenta case ERwin, a tabelas são nomeadas, de modo geral, combinando-se o nome de uma tabela primária com o de uma secundária.  Quando a entidade (tabela) tem característica independente (primária) dá-se um nome único (ex: Bancos).  Se a entidade aparece relacionada ou dependente (secundária) de outra, dá-se um nome composto pelos nomes das duas entidades (ex: Bancos_Layout).  Tabelas têm o nome no plural ou no singular
Transação	·       Uma transação, para existir, deve ser cadastrada no Visual Linx.  Essa transação
Variável	·       Variáveis e arrays declaradas como LOCAL, PRIVATE e REGIONAL devem ter seus nomes iniciados por “X” (ex: xRegAtual); variáveis e arrays declaradas como PUBLIC devem começar com “W” (ex: wNivelAcesso)
View	·       As views (Select Sql) devem ser salvas com nomes assim “v_nometabela_zz”, onde nometabela é o nome da tabela no banco de dados; zz é um número seqüencial de view sobre aquela tabela (ex: v_Bancos_LayOut_00 é a primeira view sobre a tabela Bancos_LayOut; v_Bancos_LayOut_01 é a segunda view sobre a mesma tabela

A Linx costuma utilizar o recurso de nomes extensos; a view “v_romaneios_reservas_00_estoque_disponivel” é um exemplo disso.

DESENVOLVIMENTO DE TRANSAÇÕES  PADRÃO LINX

TELAS/FORMS passo-a-passo

2.     Registrar a transação na tabela de Transações do Banco de dados e seus parâmetros.

·       A criação de uma nova transação no Linx precisa ter um numero de controles na tabela de transações. Este Registro deve ser criado no modulo de utilitários do Sistema onde você vai definir o titulo e o local de navegação/Menu onde a form será ativada.

·       Não se esqueça que os números de controle devem ser definidos com 6 números pois a sua form terá o nome no diretório definido por estes 6 números mais LX. Exemplo LX002005.scx

·       Na form de transações você poderá também definir parâmetros locais da sua Form que já existam na tabela de parâmetros .

3.       Criar e registrar os parâmetros para as transação na tabela de Parâmetros.

Parâmetros servem para definir aqueles dados onde cada usuário do sistema pode ter um diferente como por exemplo qual a LINHA DEFAULT de produtos ou COLEÇÃO DEFAULT.

Estes parâmetros devem são utilizados em cada transação como se fossem propriedades locais de cada  Formset.  A forma de utiliza-los é THISFORMSET.PP_nome_parametro.

1. Criar um novo form e selecionar uma Biblioteca de Classes Visuais da Linx

·       abrir um projeto (.pjx) existente e executar o “Linx_102”;

·       criar um novo form, em branco (new form);

·       salvar o novo form (ver tópico “Esquema Linx de Nomenclatura”);

·       na barra de ferramentas “Form Controls”, clicar no botão “View Classes”, e escolher “Lx_Class”;

falta img

biblioteca \Linx_Sql\Desenv\Lib\Lx_Class.Vcx

Ou ainda,

·       na barra de ferramentas “Form Controls”, clicar no botão “View Classes”, e escolher “Lx_Tools”;

falta img

     biblioteca \Linx_Sql\Desenv\Lib\Lx_Tools.Vcx

Obs.: a partir daqui, a barra de ferramentas “Form Controls” será referenciada pelo nome da biblioteca nela selecionada: “Lx_Class” ou “Lx_Tools”.

2. Criar e nomear um FormSet para a nova tela

·       na barra de ferramentas “Lx_Class” selecionar o controle “Lx_FormSet_Form”;

·       clicar no corpo do novo form para inserir o controle formset selecionado;

·       responder “Yes” para a pergunta: “Replace current form set object?”.  Está estabelecido, então, um formset e um form derivados da classe padrão Linx “Lx_FormSet_Form”.  Normalmente não se acrescentam novos forms a esse formset.  O form criado já possui um objeto chamado “foco”, com a função de evitar que qualquer outro objeto seja focado quando o form iniciar;

·       nomear o formset, propriedade NAME (ver tópico “Esquema Linx de Nomenclatura”);

·       fazer a propriedade do formset p_Formset_Table = .T., se o form for do tipo table;

·       fazer a propriedade do formset p_Formset_Consulta = .T., se o form for do tipo consulta;

3. Compor o DataEnvironment do novo FormSet

·       codificar “Set Deleted On” no evento BeforeOpenTables do objeto DataEnvironment;

·       adicionar no DataEnvironment as views necessárias, trazidas APENAS do banco de dados temporário de views “Lx_Temp”; comece preferencialmente pela view pai, depois views filhas e depois views valida;

·       nomear (propriedade NAME) cada objeto cursor de cada view (ver tópico “Esquema Linx de Nomenclatura”);

·       codificar “ThisFormSet.L_View_Init(“PAI”,This.Alias)” no evento Init do cursor da view pai;

·       codificar “ThisFormSet.L_View_Init(“FILHA”,This.Alias)” no evento Init dos cursores das views filhas;

2. Inserir no form da nova tela os principais Containers

·       selecionar na barra de ferramentas “Lx_Class” o controle “Lx_PageFrame”, e inserí-lo na metade inferior do form (se necessário);

·       selecionar na barra de ferramentas “Lx_Class” o controle “Lx_Grid_Filha”, e inserí-lo na Page1 do pageframe (se necessário);

Costuma-se deixar forms, pageframes, pages e grids com os nomes derivados de suas classes pai.  Uma page não precisa necessariamente conter uma grid, pode-se inserir outros controles na page.  Semelhantemente, uma grid poderia ser colocada diretamente no form, e poderia descender da classe Lx_Grid_Base.  Costuma-se também utilizar a metade superior do form para dados da view/tabela pai e a inferior para dados da(s) view(s)/tabela(s) filha(s)

nova tela: pronta para o builder

4. Executar o Builder Linx sobre a nova tela

·       selecionar o form da nova tela;

·       executar o builder: no projeto selecionar “Lx_Build” e clicar no botão “Run”;

No builder, em essência, seleciona-se um campo, um objeto e um container.   O campo será definido como propriedade ControlSource do objeto que, por sua vez, será inserido no container.

builder da Linx “\Linx_Sql\Desenv\FormTool\Lx_Build.Scx”

·       configurar o builder para a geração adequada dos objetos;

1.     definir o tipo do form: table ou consulta.  Deixar em branco se for do tipo pai com filha(s) para entrada de dados;

2.     apontar um dos containers do formset, para ser container destino dos objetos a serem gerados;

3.     indicar a view/tabela origem dos campos, cujos dados serão alterados pelos controles.  Os campos  da view indicada aparecem na lista de campos não selecionados;

4.     assinalar a view indicada, como sendo baseada em tabela pai “TP” ou tabela filha “TF”;

5.     selecionar, através dos botões seletores de campos, os campos a serem utilizados nos objetos, nesta operação com o builder;

6.     estabelecer a ordem dos campos, arrastando-os para cima ou para baixo.  Esta é a ordem em que os controles serão posicionados no container destino;

7.     vincular um objeto Linx a cada campo selecionado, clicando no campo e em seguida no objeto.  O objeto TextBox é assumido como default, se nenhum outro for selecionado;

8.     construir os objetos clicando no botão construtor, que exibe o nome do container destino, onde os controles serão inseridos.

É importante notar que o builder cria somente objetos que tenham um campo da view/tabela como propriedade ControlSource, isto é, não é possível inserir um objeto livre, sem vínculo com campos de dados.

Este item 4 (“Executar o Builder sobre a nova tela”) descreve uma operação completa com o builder.  Operação de termina com a inserção dos objetos no container destino.  Pode-se, numa só operação com o builder, destinar vários objetos para vários destinos.  Recomenda-se porém, que se realize tantas operações quantos forem os containers destino - uma operação para cada container.

5. Rearranjar o layout da tela modificada pelo Builder

·       redimensionar os objetos;

·       reposicionar objetos; de preferência com os dados do registro Pai na metade superior do form;

·       alterar, se necessário, a propriedade capiton dos labels colocados pelo builder;

·       alterar a propriedade capiton das pages, se houver pageframes;

·       alterar, se necessário, a propriedade caption dos cabeçalhos inseridos pelo builder na grid;

·       adicionar na nova tela, se necessário, novos objetos não vinculados a campos de view/tabela;

·       selecionar, na barra de ferramentas “Lx_Tools”, a classe “Lx_Frame_3d” e colocar uma frame ao redor do objeto da chave primária e seu label, na área Pai do form.  Para ser ter uma idéia disso, pode-se abrir e observar um form pré-existente;

·       inserir outros controles, se necessários;

6. Setar propriedades e confirmar as setadas pelo builder (algumas)

·       fazer, no objeto da chave primária:

   ForeColor=vermelho

·       fazer, no label da chave primária:

   ForeColor=vermelho

   FontSize=15 (aproximadamente)

·       fazer, no pageframe e na grid:

   p_Resize_Horizontal= .T.

   p_Resize_Vertical= .T.

·       fazer, no formset:

   p_FormSet_Table=.F.  (.T., se form tipo tabela)

   p_FormSet_Consulta=.F. (.T., se form tipo consulta)

   p_Primeiro_Objeto=nome_controle  (1o. objeto do form)

   p_Filhas_Primeiro_Objeto=nome_controle  (1o. objeto da grid ou page)

·       fazer, na view (cursor) pai:

   NoDataOnLoad= .T.

   ReadyOnly= .F.

   BufferMode=3  (5, se form tipo tabela; 1, se tipo consulta)

·       fazer, nas views filhas:

   NoDataOnLoad= .T.

   ReadyOnly= .F.

   BufferMode=5

·       fazer, nas views validas:

   NoDataOnLoad= .F.

   ReadyOnly= .T.

   BufferMode=1

·       fazer, nos TextBox Valida:

   p_Valida_Coluna_Tabela=nome_tabela  (tabela valida)

   p_Valida_Coluna=coluna_da_tabela  (coluna da tabela valida)

·       fazer, nos ComboBox Valida:

   RowSource=tabela.coluna   (tabela valida, “.” ponto, sua coluna)

7. Criar propriedades, Codificar eventos e métodos

·       codificar, em cada pageframe.page.ACTIVE

   This.Refresh()

·       criar no formset, se necessárias, novas propriedades  (ver tópico “Esquema Linx de Nomenclatura”);

·       criar no formset, se necessários, novos métodos  (ver tópico “Esquema Linx de Nomenclatura”);

·       CODIFICAR NOS MÉTODOS ADEQUADOS toda a programação desejada (o desenvolvimento mais significativos ocorre aqui);