Classe e ADO

[JoséQuintas]

E porque seria diferente.
em dbf:

Código: Selecionar todos

PROCEDURE pAuxCnae

   LOCAL oFrm := AUXCNAEClass():New()

   IF ! AbreArquivos( "jptabel" )
      RETURN
   ENDIF
   oFrm:Execute()
   CLOSE DATABASES

   RETURN

em mysql:

Código: Selecionar todos

PROCEDURE pAuxCnae

   LOCAL oFrm := AUXCNAEClass():New()

   oFrm:Execute()

   RETURN

[JoséQuintas]

A classe usa herança da geral
Mas... é diferente pra mostrar a descrição, porque só usa os primeiros 5 dígitos...

Código: Selecionar todos

CREATE CLASS AUXCNAEClass INHERIT AUXILIARClass
...
METHOD Descricao( maxCnae ) CLASS AUXCNAEClass

   RETURN ::Super:Descricao( Left( maxCnae, 5 ) )

na auxiliar geral:

Código: Selecionar todos

CREATE CLASS AUXILIARClass INHERIT frmCadastroClass
...
METHOD Descricao( cCodigo ) CLASS AUXILIARClass

   LOCAL mTexto

   IF Empty( ::cDataTable )
      Encontra( ::cTabelaAuxiliar + cCodigo, "jptabel", "numlan" )
      mTexto := jptabel->axDescri
   ELSE
      mTexto := ADOField( "AXDESCRI", "C", "JPAUXILIAR", "AXTABELA=" + StringSql( ::cTabelaAuxiliar ) + " AND AXCODIGO=" + StringSql( cCodigo ) )
   ENDIF

   RETURN mTexto

É que tem tabela em DBF e em MySQL... então ainda preciso manter as duas opções

Mas ao invés de criar uma nova rotina de pesquisa... se a diferença são 5 caracteres, passo os 5 pra rotina que já existe.

[JoséQuintas]

o browse... automático... neste caso em ADO

[JoséQuintas]

Tá aí uma coisa interessante.....

Enquanto muitos aqui procuram IDEs pra desenhar telas gráficas....

Eu vou querer saber depois qual vai ser a LIB gráfica que vai aceitar classe/herança em telas, pra não ter que ficar desenhando cada tela !!!

[rochinha]

Amiguinhos,

JoséQuintas daqui a pouco você vai querer ou criar uma classe que pegue herança de um sistema e não precise programar denovo. kkkkkkk

Sabe que eu já pensei nisto que você falou, é um saco e creio até que ultrapassado criar telas para os programas. Tudo tem de ser mais dinamico.

Na fivewin, tem um pequeno programinha que pega um DBF e criar com comandos de tela uma tela baseada em DBF igual ao wizard do Visual Basic 6.

Era interessante pois facilitava tal trabalho mas era algo avançado demais para os usuários de nossos sistemas acostumados a tela bem elaborada e visualmente intuitivas.

O problema é que não era on-the-fly as telas criadas pelo aplicativo, tinha de ser compiladas.

Geralmente um dicionário permite definir os campos que irão para a tela, comportamento(habilitado ou não, máscara, validação etc.

Creio que depois disto seja possível fazer o que você pensa. Ou não.

[JoséQuintas]

Creio que depois disto seja possível fazer o que você pensa. Ou não.

Eu penso numa coisa simples: O Visual Basic 6, há 20 anos atrás permitia isto.
A HMG é indiscutivelmente baseada no VB5, mas sem nenhum recurso prático do VB5.

SE eu fosse usar HMG, a primeira coisa seria alterar toda forma de fazer as coisas, porque basicamente ela é movida a limitações.
O que ela não limita por fonte, ela limita por causa dos CHs.

Eu acho até que logo nos primeiros programas, o pessoal da HMG vai ficar de boca aberta com o que eu fizer.
É sério... o simples fato de não usar os arquivos #define, expandem muito as possibilidades.

Cheguei a fazer um mini gerador de telas em VB6.
Sabe como é no VB6?
Você define UM button, UM textbox, UM label, e define como array.
A partir daí, pode multiplicar por quantas vezes quiser, e definir as propriedades de cada um.
É simples assim.

[JoséQuintas]

Cheguei a fazer um mini gerador de telas em VB6.
Sabe como é no VB6?
Você define UM button, UM textbox, UM label, e define como array.
A partir daí, pode multiplicar por quantas vezes quiser, e definir as propriedades de cada um.
É simples assim.

Correção:
Não era um gerador de telas, o gerador de telas VB6 era em Clipper....
Esse daí era um programa de edição de arquivos DBF, que se criava em run-time.
Eu chamava esse módulo/formulário passando o nome do DBF, e ele já se transformava na edição do DBF.
Podia chamar quantas vezes quisesse, com o nome do DBF que quisesse.
No caso de muitos campos, tudo era dividido em abas.

[rochinha]

Amiguinhos,

JoseQuintas

Então esta ai o inicio de uma classe que pode facilitar em muito aos preguiçosos como eu, kkkkkk.

Quando você fala "dividir em abas" com certeza isto acontece na sequencia em que foram criados os campos, tipo, cabem 20 campos por aba, 20+1 abre nova aba, 40+1 abre nova aba, etc. Tô certo.

Porque se for para criar abas definindo quais campos terão importância de aparecer na primeira, segunda, etc será necessário um terceiro arquivo com definições, tipo .INI.

Eu cheguei a codificar algo parecido com a versão antiga do SmartSheets:



A tela era dividida em duas partes, na esquerda tinha o menu e na direita ficavam os browse. Conforme clicava em um menu uma nova aba era adicionada a interface abrindo o browse com a tabela. Até aqui já estava estruturado e eu iria codificar a tela de edição gerando automaticamente os GETs, combos, listboxes, etc. Mas perdi o harddisk com todo o trabalho.

[JoséQuintas]

Uia...
2008 O fonte mais antigo

2013, quando foi apagado, usava rotina pra configurar conforme conteúdo

A rotina acima é a geração de textbox/label em tabs, e também a geração dos buttons.


O VB6 não tem geração em PDF, mas o Windows 10 atual faz isso automático.
ADO... é comum pra ele, é "nativo" como gostam de dizer por aqui...
Programa pra desenhar relatórios: duas opções disponíveis Crystal Reports e Data Reports (não tenho certeza sobre uma terceira opção, já esqueci)
Criar controles próprios.... normal

Não é interessante?
Um produto com mais de 11 anos.
Produto comercial, custou 500 reais em 5 vezes sem juros.... completo.

Aí vamos para o Harbour open-source... e qualquer componente custa muito mais que isso...
E os usuários acham tudo normal... vai entender...
É que aproveitam os fontes... que precisam ser reescritos... kkkk

[JoséQuintas]

Nota sobre os controles:

Eu usava tudo como array, nem importava o nome, em TAG eu colocava a configuração.
Então, no validate() ou on change() ou on lostfocus() ou outro, bastava conferir a tag.

Era algo como GET x PICTURE x VALID Validax( X ) WHEN Whenx( X )

Uma única rotina pro aplicativo inteiro pra validar e/ou formatar, etc.
É comum no VB6, quando um controle é array, existe uma única função que atende todos.
Eu extendi isso ao aplicativo inteiro.

Pra quem acha isso complexo, algo como isto no Harbour:

Código: Selecionar todos

... GET cCampo VALID Validalocal( @cCampo )
...
FUNCTION ValidaLocal( cCampo )
   RETURN ValidaGeral( @cCampo )

FUNCTION ValidaGeral( cCampo )

   DO CASE
   CASE GetActive():Tag == "CODCLIENTE"
      RETURN OkCliente( @cCampo )
   ENDCASE
   RETURN .T.

A IDE desviava pro local, mas eu alterava o local pra chamar o geral.
Pra que criar trocentas validações de clientes, se é sempre a mesma coisa, e uma só já resolve?

Nota: os controles são classes, então tá no assunto ainda, apesar de ser outra linguagem de programação, os controles das LIBs gráficas poderiam ter os mesmos recursos práticos.

[JoséQuintas]

E não é que achei um elo de ligação com o Harbour.....

A Getsys do Harbour é um array....
E cada elemento é uma classe, que tem lá a linha, coluna, e até a TAG.
É como se eu colocasse elementos na GetSys, configurando linha, coluna, e valor na tag....

A diferença é que em ambiente gráfico, tudo está na "getsys", não apenas os gets.
Então, na prática, o que fiz foi alimentar a "getsys" com os campos....

Igual fazemos com relatórios, ir somando coluna, chegou em MaxCol() joga pra linha de baixo, chegou em MaxRow() joga pra próxima aba.

Todo mundo já fez algo assim, em ambiente gráfico é a mesma coisa.