PC Toledo

Estou meio sem inspiração, e vi que tá faltando coisa no dlgauto.
Talvez porque tem todas as LIBs juntas, ou porque tem DBF e MySQL, que dependem de solução diferente.
Talvez todos possam ajudar a continuar o que falta, já que qualquer lib serve.

Basicamente é o que fazemos no dia a dia.

Como criamos qualquer cadastro, ou um cadastro de clientes:
código, nome, endereço, etc. a estrutura

O que tem no cadastro?
Opções inclui, altera, exclui, consulta, etc.

Como criamos a tela?
definimos o código, que é o campo chave, e o resto são campos a serem digitados.

TODO cadastro é assim.

O dlgauto cria os "BUTTONs", os "SAYs", e os "GETs", pra qualquer cadastro, afinal é tudo igual, só mudam os campos.

Pra isso ele pega a estrutura automaticamente, de DBFs ou SQL.
E resta definir o campo chave, por exemplo, o código de cliente como chave do cliente.
A partir daí, faz lá a tela com tudo, pra navegação, que é sempre igual.

Além disso, tem opção de escolher controle diferente, controle pra escolher data em calendário, ou pra avançar/voltar num contador, e outros.
Isso não altera o conceito inicial, é apenas trocar o "GET" por um "DATE PICKER" ou outro, conforme o que a LIB tiver disponível.

É o que todo mundo faz, o tempo todo, só que automático.

O que mais podemos ter num cadastro:
Tem o browse, pra escolher na lista.
Nisso é pegar a lista da estrutura e montar o browse, é o que fazemos normalmente.

Até aqui é o básico de um cadastro, só precisamos saber o campo chave, e os demais campos, e o tipo de cada um: caractere, numérico, data, etc.
Fazer SAY, fazer GET, fazer BROWSE.... é tudo coisa comum.
Ao invés de ficar olhando lá a estrutura, e fazer manual, o dlgauto faz automático, porque é só acessar a estrutura e pegar os nomes.

Pra fazer tudo isso, uso um array com a lista de campos, esse é o ponto de partida.
Como pode ter um texto descritivo do que é cada coisa, entra lá nesse array "Código", por exemplo.
Pra digitação isso precisa variável, então tem lá no array o elemento que vai ser usado como GET.
Em GUI isso vai usar controles, LABEL (SAY) e TEXTBOX (GET), então tem lá no array os elementos que serão o controle label e o controle textbox (ou date picker, ou outro)

O que o dlgauto faz, na hora de criar a tela disso é chamar rotinas que "traduzem" a criação de cada item pra cada lib.
As telas são em pixels, então os tamanhos e posições são iguais pra todas as LIBs, a montagem disso pode ser genérica.
Criar button, criar textbox, criar label, a parte genérica é igual pra todas as LIBs, o que muda é o detalhe específico de cada LIB.

Temos até aqui um cadastro genérico básico, que todo mundo faz, mas sempre digitando tudo, mesmo quando copia/cola fontes.
O dlgauto apenas acaba com esse copiar/colar, e faz a parte repetitiva.

Depois entraram os campos validados, também normal no dia a dia.

Tem lá o pedido e vai digitar o código de cliente.
O que todo mundo faz: no VALID faz a pesquisa, e mostra o nome.
O mesmo pra produto, fornecedor, e tudo mais, sempre a mesma coisa.
É mais outra coisa repetitiva, que o dlgauto faz.

Pra isso, dlgauto não faz nada diferente:
No campo é definir aonde vai ser feita a pesquisa, e qual será o retorno considerado descrição.
Consultar código e trazer nome, que poderia ser no arquivo de clientes, no arquivo de produtos, etc.
Pra fazer automático depende de configuração.
Normal, pra nós é assim também.
no campo código de cliente, pesquisar cadastro de cliente, trazer nome do cliente.
no campo código de produto, pesquisar cadatro de produto, trazer nome do produto.
É sempre igual, fez um fez todos, só muda o nome de cada um.
Se o dlgauto sabe o nome de campo, tabela, e descrição, ele faz sozinho.
Também pode ter um browse pra pesquisar isso, depende qual é o campo e qual tabela "destino".
E pra tudo isso, tanto faz se é DBF ou MySQL, muda o jeito de buscar informação, mas não a lógica do que precisa ser feito.

Já temos algo mais completo: cadastros com pesquisa de códigos relacionados
E tanto faz qual seja a LIB, não tem muita opção de fazer diferente, só tem o fonte de cada lib construir as telas.

O último adicionado foi o mais complexo, talvez.
Como exemplo e base: pedidos
Temos lá o cadastro de pedidos, mas o pedido precisa daquele browse com os produtos do pedido.
Como fazemos isso?
O campo "chave" vai ser o pedido, "filtramos" no browse tudo com aquele número de pedido.
Assim temos o browse dos produtos daquele pedido.
Mas não é só isso, tem também a edição desses produtos do pedido.

O dlgauto já não faz telas automáticas pra cada DBF ?
Então... nisso temos pronto o que seria a edição do arquivo de produtos do pedido.
É só chamar a partir desse browse, conforme escolhe pra incluir/alterar/excluir.

O mesmo estilo de browse serve pra outras coisas, de mesmo estilo de funcionamento: browse de outra tabela fazendo filtro de um campo da tabela atual.
Nos pedidos: mostra o arquivo itens de pedido, filtrado por pedido
Podemos em cliente, mostrar o financeiro, filtrado por cliente
Podemos nos produtos, mostrar o movimento filtrado por produto
E browse pra qualquer situação parecida.
Talvez opção nesses browses de editar ou não essa lista.

E tudo automaticamente, a partir de uma configuração.
A configuração básica, dos campos, vém das estruturas.
A configuração dos relacionamentos precisa ser feita manualmente.
A configuração pra ter esses browses extras idem.
Isso dá quase tudo que um aplicativo poderia ter.

Agora vamos às pendências/falhas, por ser diferente por LIB/DBF/MySQL:

- precisa browse diferente pra DBF e pra SQL, nem toda lib tem recurso para os dois
- Acionar uma pesquisa em browse, pode ser por tecla ou button, nem toda lib tem recurso pra isso, e em algumas isso falha
- ao teclar enter no browse, precisa uma reação, não é igual pra toda lib, nem igual pra DBF/MySQL Seria pegar o resultado pra digitar/preencher campo na tela
- Essas coisas acima podem criar exceções, precisam ser tratadas de uma forma que a parte genérica acione as exceções, de uma forma que a compilação não seja afetada - não dá pra colocar rotina de uma lib no fonte de outra.

São detalhes desse tipo que faltam.
Como resolver determinadas questões em determinadas LIBs.
Ou detalhes do browse: temos aqui 2 situações de browse, que podem ser consideradas 4, já que pode ser DBF ou MySQL.

É tudo coisa que já uso no aplicativo em GTWVG, mas no aplicativo faço tudo manual, com classes e herança.
E em console mais fácil, fica mais sob controle a questão de ENTER ou CLICK no browse, e um KEYBOARD do resultado.
Já em GUI, o browse depende de cada LIB, e a utilização/atualização a partir do resultado também.
Só quem usa cada lib é que vai conhecer uma solução pronta pra isso, a ser modificada pra genérica/automática.

Qual o princípio do dlgauto?
Vai criar a tela, então por exemplo vai criar os buttons.

Praticamente sempre tem a Dialog, o Parent, nome/variável do controle, "linha", "coluna", "altura", "largura", texto do button, ícone, e a ação.
Não importa a LIB.

Código: Selecionar todos

GUI():ButtonCreate( xDlg, xParent, @xControl, nRow, nCol, nWidth, nHeight, cCaption, cResName, bAction )

É aí que entra uma classe pra cada lib.
Como tudo é em pixel, é igual pra todas as libs, mas cada lib tem seu jeito de criar o button.
Nem todas usam todos os parâmetros, mas a chamada precisa ser padrão.

Em lib_hwgui.prg.

Código: Selecionar todos

STATIC FUNCTION gui_ButtonCreate( xDlg, xParent, xControl, nRow, nCol, nWidth, nHeight, cCaption, cResName, bAction )

   @ nCol, nRow BUTTON xControl ;
      CAPTION  Nil ;
      OF       xParent ;
      SIZE     nWidth, nHeight ;
      STYLE    BS_TOP ;
      ON CLICK bAction ;
      ON INIT  { || ;
         BtnSetImageText( xControl:Handle, cCaption, cResName, nWidth, nHeight ) } ;
         TOOLTIP cCaption

   ( xDlg )

   RETURN Nil

Em lib_fivewin.prg
Note que fivewin tem um recurso que define no button pra abortar VALID, usei para button com texto "Cancel" ou "Exit"

Código: Selecionar todos

STATIC FUNCTION gui_ButtonCreate( xDlg, xParent, xControl, nRow, nCol, nWidth, nHeight, cCaption, cResName, bAction )

   IF cCaption == "Cancel" .OR. cCaption == "Exit"
      @ nRow, nCol BUTTONBMP xControl PROMPT cCaption OF xParent ;
         SIZE nWidth, nHeight PIXEL RESOURCE cResName TOP ACTION Eval( bAction ) CANCEL
   ELSE
      @ nRow, nCol BUTTONBMP xControl PROMPT cCaption OF xParent ;
        SIZE nWidth, nHeight PIXEL RESOURCE cResName TOP ACTION Eval( bAction )
   ENDIF

   (xDlg);(xControl);(nRow);(nCol);(nWidth);(nHeight);(cCaption);(cResName);(bAction)

   RETURN Nil

Em lib_hmg3.prg
Note que HMG3 faz uso do nome do controle.
Uso newname() para criar sempre um nome únco pra cada button.

Código: Selecionar todos

STATIC FUNCTION gui_ButtonCreate( xDlg, xParent, xControl, nRow, nCol, nWidth, nHeight, cCaption, cResName, bAction )

   IF Empty( xControl )
      xControl := GUI():NewName( "BUTTON" )
   ENDIF

   DEFINE BUTTON ( xControl )
      PARENT ( xParent )
      ROW           nRow
      COL           nCol
      WIDTH         nWidth
      HEIGHT        nHeight
      CAPTION       cCaption
      // do not show ico ??
      PICTURE       cResName
      // default // PICTALIGNMENT TOP
      ACTION         Eval( bAction )
   END BUTTON

   (xDlg);(xControl);(nRow);(nCol);(nWidth);(nHeight);(cCaption);(cResName);(bAction)

   RETURN Nil

Em lib_hmge.prg (HMG Extended)
Mesma coisa de HMG3 referente ao nome do controle.
Aqui usando o formato livre, achei mais interessante/flexível, onde cada linha fica independente.

Código: Selecionar todos

STATIC FUNCTION gui_ButtonCreate( xDlg, xParent, xControl, nRow, nCol, nWidth, ;
   nHeight, cCaption, cResName, bAction )

   IF Empty( xControl )
      xControl := gui_NewName( "BTN" )
   ENDIF

   DEFINE BUTTONEX ( xControl )
      PARENT ( xParent )
      ROW         nRow
      COL         nCol
      WIDTH       nWidth
      HEIGHT      nHeight
      ICON        cResName
      IMAGEWIDTH  -1
      IMAGEHEIGHT -1
      CAPTION     cCaption
      ACTION      Eval( bAction )
      FONTNAME    APP_FONTNAME
      FONTSIZE    7
      FONTBOLD    .T.
      FONTCOLOR   COLOR_BLACK
      VERTICAL   .T.
      BACKCOLOR  COLOR_WHITE
      FLAT       .T.
      NOXPSTYLE  .T.
   END BUTTONEX

   (xDlg)

   RETURN Nil

E por fim lib_oohg.prg
OOHG tem opção tradicional igual as outras minigui, ou objeto.
Note que. igual fivewin, tem a opção de button que cancela VALID

Código: Selecionar todos

STATIC FUNCTION gui_ButtonCreate( xDlg, xParent, xControl, nRow, nCol, nWidth, nHeight, cCaption, cResName, bAction )

   IF Empty( xControl )
      xControl := gui_NewName( "BUTTON" )
   ENDIF

   IF cCaption == "Cancel"
      @ nRow, nCol BUTTON ( xControl ) ;
         PARENT ( xParent ) ;
         CAPTION  cCaption ;
         PICTURE  cResName ;
         ACTION   Eval( bAction ) ;
         WIDTH    nWidth ;
         HEIGHT   nHeight ;
         IMAGEALIGN TOP ;
         CANCEL // abort valid
   ELSE
      @ nRow, nCol BUTTON ( xControl ) ;
         PARENT ( xParent ) ;
         CAPTION  cCaption ;
         PICTURE  cResName ;
         ACTION   Eval( bAction ) ;
         WIDTH    nWidth ;
         HEIGHT   nHeight ;
         IMAGEALIGN TOP
   ENDIF

   (xDlg)

   RETURN Nil

É assim que dlgauto funciona.
Ele faz a parte genérica, e chama cada LIB de forma genérica, cada LIB que crie as coisas do seu jeito.

Por isso dá pra compilar dlgauto com qualquer lib.
O fonte dele é genérico, e cada lib tem seu lib_xxxx.prg pra completar.

: hmge.png (313.06 KiB) Exibido 71 vezes

Em lib com recurso a mais, ou recurso que eu soube usar, eu acrescentei recurso.
Essa tela é HMG Extended.
Acrescentei imagem em cada aba da tab
Acrescentei o botão de pesquisa nos campos chave.
Alguns "GETs." foram substituídos pela opção de checkbox, ou calendário, ou outro.

: ticket.png (108.57 KiB) Exibido 67 vezes

Tá praticamente igual em qualquer lib, esta em fivewin, dá pra notar pequenas diferenças no visual que pertencem a fivewin.
Seria como pedidos, e produtos do pedido.
Tem os ícones pra mexer nos produtos do pedido - adicionar, excluir ou editar.
Sempre automático, conforme configuração.

: cli.png (139.34 KiB) Exibido 65 vezes

Como o recurso fica disponível, e pra testes quanto mais coisas melhor, em clientes coloquei opção de ver financeiro e estoque em nome daquele cliente.

: varios.png (328.77 KiB) Exibido 63 vezes

A coisa pode ir longe, vários níveis.

Aqui abri clientes, com browse dos pedidos.
Cliquei no pedido abriu com browse dos produtos.
Cliquei no produto e abriu o lançamento do produto.

Como eu disse antes, se o dlgauto já cria tela pra qualquer coisa, foi só ir usando.
E usando chamadas genéricas pra qualquer lib.

Virou um testador de LIBs.
Será que a LIB faz ? Será que precisa algo especial ? Como é em cada LIB ? Será que tem recurso que facilita ?
Será que a LIB aguenta vários controles e várias telas ?
E por aí vai.
Várias situações simuladas automaticamente, o que fazendo fonte nem sempre pegaria todas as situações diferentes.
E é praticamente tudo que usamos num aplicativo, que eu me lembre, ou pelo pouco uso em GUI que tenho.

Agora é acertar alguns detalhes que estão falhando, conforme a lib.
E ver o que mais poderia ser testado.

Isso tudo em DBF.
Em SQL depende de cada LIB, ainda está mais limitado pra SQL.

PC Toledo

DLGAUTO - continuação

DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação

Re: DLGAUTO - continuação