DLGAUTO Dialogs automáticas (não geração de fontes)

[JoséQuintas]

Agora também em HMG3.

https://www.youtube.com/watch?v=XERYt6V4mvI



Solução básica: se dá erro nas rotinas de UNICODE, só fixar ANSI.
O que isso tem a ver com níveis de dialog eu não sei, mas tem a ver com o erro, e resolveu.

[JoséQuintas]

login.png (11.71 KiB) Exibido 20430 vezes

Só o primeiro protótipo de LOGIN, por enquanto só HMG.
Mas as rotinas do dlgauto estão presas ao tipo de variável.

Código: Selecionar todos

#include "hmg.ch"
#include "i_winuser.ch"
#include "i_altsyntax.ch"
#include "frm_class.ch"

MEMVAR lLogin, cUser, cPass

FUNCTION test_Login()

   LOCAL xDlg, aControl := Array(6), aItem

   FOR EACH aItem IN aControl
      aItem := EmptyFrmClassItem()
   NEXT

   gui_DialogCreate( @xDlg, 0, 0, 300, 200, "Login", , .T. )

   gui_LabelCreate( xDlg, @aControl[1][CFG_FNAME], 10, 10, 80, 20, "User" )
   gui_TextCreate( xDlg, @aControl[2][CFG_FNAME], 10, 90, 100, 20, cUser,,,,,,aControl[2] )
   gui_LabelCreate( xDlg, @aControl[3][CFG_FNAME], 40, 10, 80, 20, "Password" )

   DEFINE TEXTBOX ( aControl[4][CFG_FNAME] )
      PARENT ( xDlg )
      ROW 40
      COL 90
      WIDTH 100
      PASSWORD .T.
      VALUE cPass
      UPPERCASE .T.
   END TEXTBOX

   gui_ButtonCreate( xDlg, @aControl[5][CFG_FNAME], 80, 45, 50, 20, "Login",, { || Login_Click( xDlg ) } )
   gui_ButtonCreate( xDlg, @aControl[6][CFG_FNAME], 80, 115, 50, 20, "Cancel",, { || Cancel_Click( xDlg ) } )

   DoMethod( xDlg, "CENTER" )
   DoMethod( xDlg, "ACTIVATE" )

   (cUser);(cPass)

   RETURN Nil

STATIC FUNCTION Login_Click( xDlg )

   lLogin := .T.
   gui_DialogClose( xDlg )

   RETURN Nil

STATIC FUNCTION Cancel_Click( xDlg )

   IF gui_MsgYesNo( "Exit?" )
      gui_DialogClose( xDlg )
   ENDIF

   RETURN Nil

Aí está no jeito, meio caminho andado pra qualquer LIB, só depende da rotina de textbox pra senha.

Então.... só estou usando o que já existe de GUI no dlgauto.
Já tem dialog, já tem label, já tem textbox, já tem button....
Só precisei do textbox pra senha, que por enquanto ainda não tem.

[JoséQuintas]

Código: Selecionar todos

#include "frm_class.ch"

MEMVAR lLogin, cUser, cPass

FUNCTION test_DlgLogin()

   LOCAL xDlg, aControl := Array(6), aItem

   FOR EACH aItem IN aControl
      aItem := EmptyFrmClassItem()
   NEXT

   gui_DialogCreate( @xDlg, 0, 0, 300, 200, "Login", , .T. )

   gui_LabelCreate( xDlg, @aControl[1][CFG_FNAME], 30, 20, 80, 20, "User" )
   gui_TextCreate( xDlg, @aControl[2][CFG_FNAME], 30, 90, 170, 20, cUser,,,,,,aControl[2] )
   gui_LabelCreate( xDlg, @aControl[3][CFG_FNAME], 60, 20, 80, 20, "Password" )
   gui_TextCreate( xDlg, @aControl[4][CFG_FNAME], 60, 90, 170, 20,cPass,,,,,,aControl[4],,.T. )
   gui_ButtonCreate( xDlg, @aControl[5][CFG_FNAME], 100, 85, 50, 20, "Login",, { || Login_Click( xDlg ) } )
   gui_ButtonCreate( xDlg, @aControl[6][CFG_FNAME], 100, 155, 50, 20, "Cancel",, { || Cancel_Click( xDlg ) } )
   gui_SetFocus( xDlg, aControl[2][CFG_FNAME] )

   gui_DialogActivate( xDlg )

   (cUser);(cPass)

   RETURN Nil

STATIC FUNCTION Login_Click( xDlg )

   lLogin := .T.
   gui_DialogClose( xDlg )

   RETURN Nil

STATIC FUNCTION Cancel_Click( xDlg )

   IF gui_MsgYesNo( "Exit?" )
      lLogin := .F.
      gui_DialogClose( xDlg )
   ENDIF

   RETURN Nil

Pronto, login em TODAS as LIBs.
Criei o parâmetro de senha no gui_TextCreate()
Só fica pendente habilitar senha no textbox das outras LIBs.

O dlgauto mostra que GUI é tudo igual, não precisa ficar dividindo usuários em grupos.
Se todo mundo trabalhasse junto, melhor pra todas as LIBs, até pra saber o que melhorar, ou o que considerar bug.

Senti falta na HMG do ON ACTIVATE na DIALOG/WINDOW.

[JoséQuintas]

O dlgauto tem muita coisa interessante, o difícil é perceber.

Código: Selecionar todos

  LOCAL xDlg, aControl := Array(6), aItem

   FOR EACH aItem IN aControl
      aItem := EmptyFrmClassItem()
   NEXT

Porque FOR/EACH e não Afill() ?

Se usar Afill), todos serão o mesmo array, qualquer mudança em um deles afeta o outro.
É... porque array é por referência.
E o Afill não vai criar um array pra cada elemento, vai usar o mesmo pra todos.


Se alguma coisa não der certo, é só olhar o dlgauto.

NÃO, não tem a ver comigo, tem a ver com as situações.
Sei lá se vou lembrar de cada detalhe quando precisar de novo.....

[JoséQuintas]

Sei lá....
Tanta tela pra DBF....
Vai uma sem vínculo nenhum com DBF....

Código: Selecionar todos

/*
test_nodatabase - test with no database
*/

#include "frm_class.ch"

FUNCTION test_noDatabase()

   LOCAL oFrm, aItem, oTemp
   LOCAL aList := { ;
      { "TECODE", 0 }, ;
      { "TENAME", Space(30) }, ;
      { "TEPHONE", Space(30) }, ;
      { "TEADDRESS", Space(40) }, ;
      { "TEDOC", Space(30) } }

   oFrm := frm_Class():New()
   WITH OBJECT oFrm
      :cTitle      := "simple test"
      :cOptions    := ""
      :lNavigate   := .F.
      :lModal      := .T.
      :nLayout     := 1
      FOR EACH aItem IN aList
         oTemp := EmptyFrmClassItem()
         oTemp[ CFG_FTYPE ]   := ValType( aItem[2] )
         oTemp[ CFG_FLEN ]    := iif( ValType( aItem[2] ) == "C", Len( aItem[2] ), 10 )
         oTemp[ CFG_CAPTION ] := aItem[1]
         oTemp[ CFG_VALUE ]   := aItem[2]
         oTemp[ CFG_CTLTYPE ] := TYPE_TEXT
         AAdd( :aEditList, oTemp )
      NEXT
      :Execute()
   ENDWITH

   RETURN Nil

[JoséQuintas]

Meio sem inspieração do que mais fazer.
Mas já pensei numa coisa.

- Temos dialog que usa DBF, criada pra estrutura
- Temos dialog com campo livre, apenas digitação

Falta a mista.

Por exemplo, a dialog pedir um código "livre" de cliente e validar no arquivo de cliente, trazendo descrição.
Talvez com browse também.

Isso poderia ser usado numa diálog pra digitar o código e trazer as vendas do mês do cliente.

Numa versão do dlgauto em SQL, seria só definir o comando SQL.

A coisa dá um nó na cabeça ao pensar:

O dlgauto já faz essas coisas, não precisa criar nada novo.
Só precisa ajustar pra funcionar na nova situação.
E se tá pronto pra qualquer lib.... o que ainda nem fiz já está pronto pra qualquer lib.

Pois é, o negócio é muito doido.
Pensou em fazer,,, tá quase pronto.

Lembrando também:
Deixei uma validação reservada na configuração, mas até agora não usei.
De repente validar CNPJ, CPF, buscar tabela de preços, calcular total de produtos no pedido, e outras coisas mais.
É mesmo.... permitir adicionar buttons na dialog, pra autorizar NFE por exemplo.
Isso também já está pronto, só não está nas opções de configuração.
Esqueci disso.
Só depende de pensar em como configurar, as rotinas estão prontas.

[JoséQuintas]

Pra quem não viu:

Código: Selecionar todos

   oFrm := frm_Class():New()
   oFrm:cFileDBF   := cDBF
#ifdef HBMK_HAS_GTWVG
   oFrm:xDlg := wvgSetAppWindow()
#endif
   oFrm:cTitle     := gui_LibName() + " - " + cDBF
   oFrm:cOptions   := "IEDP"
   oFrm:aAllSetup  := aAllSetup
   oFrm:lModal     := lModal
   //AAdd( oFrm:aOptionList, { "Mail", { || Nil } } ) // example of aditional button
   //AAdd( oFrm:aOptionList, { "client", { || frm_Main( "DBCLIENT", ( oFrm:aAllSetup ), .T. ) } } )

Acima, comentado, dois buttons a mais.
Só depende de nome e ação.
O ícone vém conforme o texto, mas posso definir um padrão pra opções novas.

Está aí a tela com as duas novas opções.
Então... depende só de criar a configuração.
Tô dizendo... o negócio tá muito doido... tá criando vida própria... pensou tá pronto, pra qualquer lib.

[JoséQuintas]

Uia.....

Adicionei um tipo novo

Código: Selecionar todos

#define TYPE_ADDBUTTON  15

Adicionei a configuração, tela de DBCLIENT.DBF

Código: Selecionar todos

   aAddOptionList := { ;
      { "DBCLIENT", "Option1",  { || gui_MsgBox( "Option1" ) } }, ;
      { "DBCLIENT", "Option2",  { || gui_MsgBox( "Option2" ) } } }

Aqui carrega a configuração pro lugar certo

Código: Selecionar todos

      /* extra button */
      FOR EACH aButton IN aAddOptionList
         IF aButton[1] == cFile
            aItem := EmptyFrmClassItem()
            aItem[ CFG_CTLTYPE ] := TYPE_ADDBUTTON
            aItem[ CFG_CAPTION ] := aButton[2]
            aItem[ CFG_ACTION ]  := aButton[3]
            AAdd( Atail( aAllSetup )[ 2 ], aItem )
         ENDIF
      NEXT

Ao acionar pelo menu, adiciona, igual já existia antes

Código: Selecionar todos

   FOR EACH aItem IN ::aEditList
      IF aItem[ CFG_CTLTYPE ] == TYPE_ADDBUTTON
         AAdd( ::aOptionList, { aItem[ CFG_CAPTION ], aItem[ CFG_ACTION ] } )
      ENDIF
   NEXT

Ao executar, apenas precaução, o dlgauto me avisa que esse controle não está na lista dos controles conhecidos pelo fonte

check.png (8.99 KiB) Exibido 20409 vezes

E voilá.... a tela com os buttons definidos no setup, e executando a action também definida no setup

Repararam numa coisa:
Adicionei opções e funcionamento, sem mexer em nenhum fonte GUI.
E tá pronto pra qualquer lib GUI.
Não é incrível ?

E pra finalizar, adicionei o novo controle na lista dos que não precisam fonte extra.

[JoséQuintas]

Só novidades simples.

- Nos campos chave, funciona o click no button pra browse
- Nos campos chave, funciona o F9 pra browse

- No browse da window funcionam os buttons, ou INS, DEL, ENTER, ou clique duplo do mouse
- Nesse acionamento, está abrindo a sub-window devidamente posicionada

Nota: Isso equivale a uma tela de pedidos, pra mexer nos produtos.

Nota2: curiosidade, estou trabalhando com 1024 x 768 no dlgauto, mas como uso ampliação 150%, fica por volta de 1500 x 1000

[JoséQuintas]

Até que consegui adaptar o dlgauto pro menu fivewin sem grandes gambiarras.
Pra efeito de comparação

menu hwgui, igual a qualquer lib

Código: Selecionar todos

FUNCTION gui_DlgMenu( xDlg, aMenuList, aAllSetup, cTitle )

   LOCAL aGroupList, cDBF

   gui_DialogCreate( @xDlg, 0, 0,1024, 768, cTitle )
   MENU OF xDlg
      FOR EACH aGroupList IN aMenuList
         MENU TITLE "Data" + Ltrim( Str( aGroupList:__EnumIndex ) )
            FOR EACH cDBF IN aGroupList
               MENUITEM cDBF ACTION frm_Main( cDBF, aAllSetup )
            NEXT
         ENDMENU
      NEXT
      MENU TITLE "Exit"
         MENUITEM "&Exit" ACTION gui_DialogClose( xDlg )
      ENDMENU
   ENDMENU
   @ 400, 400 MONTHCALENDAR SIZE 250,250
   gui_DialogActivate( xDlg )

   RETURN Nil

menu fivewin, que obriga o uso de INIT, foi só dividir em dois.

Código: Selecionar todos

FUNCTION gui_DlgMenu( xDlg, aMenuList, aAllSetup, cTitle )

   gui_DialogCreate( @xDlg, 0, 0,1024, 768, cTitle )

   gui_DialogActivate( xDlg, { || gui_DlgMenu2( xDlg, aMenuList, aAllSetup, cTitle ) } )

   RETURN Nil

FUNCTION gui_DlgMenu2( xDlg, aMenuList, aAllSetup, cTitle )

   LOCAL oMenu, aGroupList, cDBF, dDate := Date(), oCalendar

   MENU oMenu OF xDlg
      FOR EACH aGroupList IN aMenuList
         MENUITEM "Data" + Ltrim( Str( aGroupList:__EnumIndex ) )
         MENU
            FOR EACH cDBF IN aGroupList
               MENUITEM cDBF ACTION frm_Main( cDBF, aAllSetup )
            NEXT
         ENDMENU
      NEXT
      MENUITEM "Exit"
         MENU
         MENUITEM "Exit" ACTION gui_DialogClose( xDlg )
         ENDMENU
      ENDMENU
      xDlg:SetMenu( oMenu )

      @ 400, 400 CALENDAR oCalendar VAR dDate OF xDlg PIXEL SIZE 220, 157 WEEKNUMBER DAYSTATE

   (xDlg);(aMenuList);(aAllSetup);(cTitle);(oMenu);(oCalendar)

   RETURN Nil

Aí no activate da dialog, uma gambiarra pra codeblock adicional.

Código: Selecionar todos

FUNCTION gui_DialogActivate( xDlg, bCode )

   IF ! Empty( bCode )
      ACTIVATE DIALOG xDlg CENTERED ON INIT DoNothing( Eval( bCode ), gui_StatusBar( xDlg, "" ) )
   ELSE
      ACTIVATE DIALOG xDlg CENTERED ON INIT gui_StatusBar( xDlg, "" )
   ENDIF

   (bCode)

   RETURN Nil

Talvez mais interessante alterar o bInit pra array, e usar AEval( aInit )
Deixar isso pra futuras versões, conforme o que acontecer.

[JoséQuintas]

dlgauto também em fivewin

https://www.youtube.com/watch?v=9BNFJaGGYKA



O dlgauto nem é importante, o que ele faz automático nem é tão importante.
O interessante é que ele virou um aplicativo cobaia de testes, simulando um aplicativo real.

O comportamento não é o mesmo em todas as LIBs, algumas situações precisaram de solução diferente, outras não sei se tem solução.

Nesse de fivewin:
- removi combobox dá erro na movimentação de campos
- o spinner está sendo exibido com tamanho errado
- há uma ocorrência estranha no browse ao abrir outra dialog
- Ainda não coloquei o evento de clique/ENTER nos browses de pesquisa

Lembrando:
O dlgauto pode ser compilado com HWGUI, HMG3, HMG Extended, OOHG, FIVEWIN
Tudo do vídeo é executado automático SEM FONTE.
É utilizada a estrutura dos DBFs na pasta, e a configuração há algum tempo pode ser feita em JSON.

[JoséQuintas]

Teste 2024

Foi só teste simples.
Teste básico é para os fracos kkkk

Como compila o dlgauto:

hbmk2 test hwgui.hbc
hbmk2 test hmge.hbc
hbmk2 test oohg.hbc
hbmk2 test gtwvg.hbc
hbmk2 test hmg3.hbc
hbmk2 test fivewin.hbc

Até aqui ok ? gera EXE em qualquer lib.

Vamos transformar tudo em LIB:

Removi do projeto o lib.prg, que é o que seleciona a lib gráfica.

hbmk2 test -DDLGAUTO_AS_LIB -hblib -odlgauto
hbmk2 lib_fivewin.prg -DDLGAUTO_AS_LIB -hblib -odlgautofivewin
hbmk2 lib_hmge.prg -DDLGAUTO_AS_LIB -hblib -odlgautohmge
hbmk2 lib_hwgui.prg -DDLGAUTO_AS_LIB -hblib -odlgautohwgui

Entenderam?
O dlgauto tem 1 PRG pra cada LIB.
E mais uns 15 PRGs que não são de nenhuma lib.
Apenas compilei separado por lib

Agora meu aplicativo oficial, dividir em linhas pra visualizar melhor:

hbmk2 jpa.hbp
-L\github\dlgauto\source
-ldlgauto
-ldlgautofivewin fivewin.hbc
-ldlgautohmge hmge.hbc
-ldlgautohwgui hwgui.hbc

LIBs originais, sem alteração.
O que será que aconteceu ?

Nota: testar uma ou várias, dá quase no mesmo

[JoséQuintas]

Faltou dizer:

SET HB_USER_LDFLAGS=-Wl,--allow-multiple-definition -s -static

acrescentei isso acima, pra fazer o mesmo do BORLAND C, de aceitar tudo repetido.

Não esperava isso mas.....

SYSTEM ERROR
Error BASE/1003 Variable does not exist: _HMG_SYSDATA
Called from MSGEXCLAMATION(0)
Called from PUTILBACKUPENVIA(215)
Called from DO(0)
Called from DOPRG(162)
Called from (b)RUNMODULE(107)

Normal, aceitou repetido, mas entrou a função da HMG Extended ao invés da minha.
Essa variável é da HMG Extended.
O default do mingw é não aceitar isso.

Talvez mover a minha pro módulo principal, sem ser por lib, pra ver se entra em primeiro lugar.
Ao invés do fonte estar em lib, entrar no projeto principal.

Acho que já sei porque o povo do borland prefere BAT, e juntar tudo que é fonte, como Borland C não dá alerta de função repetida, esses resultados inesperados são normais por lá.
No mingw ele rejeita mesmo, só aceita repetido se forçar com esse comando.

[JoséQuintas]

TODAS AS LIBS ORIGINAIS
O resultado foi esse.

É um único EXE: GTWVG, HWGUI, FIVEWIN e HMG Extended

GTWVG - faz o que o harbour pede, multithread sem problemas
HWGUI - Funciona normalmente em multithread, abri 2 dlgauto HWGUI, infinitas janelas em threads diferentes
FIVEWIN e HMG Extended - Não se deram bem entre si, tem que fazer teste delas isoladas.

Notas:
Reduzi a imagem em 4 vezes. A imagem original é 3840 x 2160, reduzi pra 1920 x 1080, por isso deve haver falha na imagem.
Pra identificar a LIB, o dlgauto mostra o nome da lib em uso, na tela vemos HWGUI e Fivewin

[JoséQuintas]

Sei lá... o fonte do aplicativo pra carregar dlgauto em cada lib.
É só isso que preciso alterar nos fontes, e também a opção no menu.
Por isso o teste, porque dá pouco trabalho.

Código: Selecionar todos

   CASE Upper( xFrmName ) == "DLGAUTOFIVEWIN"
      hb_gtReload( "WVG" )
      AppInitSets(0) // sem tela
      oGUI := FIVEWINClass():New()
      Do( "DLGAUTO", P1, P2, P3 )
      RETURN Nil
   CASE Upper( xFrmName ) == "DLGAUTOHMGE"
      hb_gtReload( "WVG" )
      AppInitSets(0) // sem tela
      oGUI := HMGEClass():New()
      Do( "DLGAUTO", P1, P2, P3 )
      RETURN Nil
   CASE Upper( xFrmName ) == "DLGAUTOHWGUI"
      hb_gtReload( "WVG" )
      AppInitSets(0) // sem tela
      oGUI := HWGUIClass():New()
      Do( "DLGAUTO", P1, P2, P3 )
      RETURN Nil
   ENDCASE

   RETURN Nil