PC Toledo

No dlgauto, coisas conhecidas:

#ifdef DLGAUTO_AS_LIB
   PROCEDURE DlgAuto
#else
   PROCEDURE Main
#endif

Se eu definir a variável DLGAUTO_AS_LIB, o programa principal vai se chamar DLGAUTO e não MAIN.
Com isso, pude criar o test.prg chamando o DLGAUTO.

Por exemplo aqui:

Código: Selecionar todos

   GUI():Init()

GUI() usa a classe. qual classe ? THREAD STATIC oGUI
Essa variável é diferente em cada thread. ela define qual a lib.
dlgauto apenas chama init() nem sabe qual lib vai ser.
É tudo relativamente simples, só definir o tipo de variável, pra ficar restrita ao alcance dela.
Lembram ? multithread é igual vários EXEs. Como ter uma variável diferente em cada EXE/Thread? só declarar THREAD STATIC.
Não precisa controle especial, não precisa inventar moda, é só definir variável como THREAD STATIC.

Todo mundo sabe escrever THREAD STATIC ? então todo mundo consegue fazer isso.
É simples assim.
Apenas não faz parte do dia a dia, então confunde sobre a utilidade/funcionamento.

É este conjunto:

Código: Selecionar todos

THREAD STATIC oGUI

FUNCTION GUI()

   RETURN oGUI

Variável STATIC só aparece no fonte que ela está indicada.
Uso a função GUI() pra obter o conteúdo da variável a partir de qualquer fonte.
Ela vai conter a classe de uma LIB, pode ser hwgui, hmge, tanto faz.
Então GUI():Init() vai chamar o init de alguma lib. Tá aí o segredo de funcionar uma lib em cada thread. (se a lib deixar)

Pronto, ativei tudo.
Criei mais uma opção -DDLGAUTO_NO_TEST
Se definir esta variável, a parte de teste não entra.

É que no aplicativo não quero que crie DBFs de teste.
No aplicativo é somente SQL.
Fazia isso usando -DDLGAUTO_AS_LIB, mas neste teste também entra como LIB.

1) o dlgauto pode ser compilado isolado como teste, é o default
2) o dlgauto pode ser compilado pra entrar como lib no aplicativo, não é default
3) o dlgauto pode ser compilado pra usar SQL, não é default
4) o dlgauto pode ser compilado pra usar os DBFs de teste, é o default

O motivo disso tudo é simples: embutir o dlgauto no aplicativo pra testes com dados reais e aplicativo real, com o mínimo de fonte extra
Este testmix.prg é um exemplo disso.
E no aplicativo, com DBFs reais (ou bases SQL), vamos criar configuração diferente do teste (ou não).

O principal problema de lib gui, é este:

Erro da HMG Extended

Código: Selecionar todos

E aí ? que erro é esse.

Quer ver de novo ?

Código: Selecionar todos

Não sabe que erro é esse ? nem eu.

Mesmo assim descobri depois:

É a famosa errorsys de LIB GUI, que quer mostrar mensagem enfeitada, mas quando o enfeite não funciona, fica sem mensagem.

Isso não acontece no meu aplicativo, porque a minha errorsys é quem manda, nem de hwgui, nem de fivewin, e se funcionasse junto, nem da minigui.
e nem mesmo a do harbour, ela é pra console, e não uso console.

Sobre as configurações....
Tem gente que gosta de ver enfeitado.

Código: Selecionar todos


#include 'hmg.ch'

FUNCTION main()

   LOCAL aList, aItem
   LOCAL xDlg := "Dlg01", xTab := "Tab01"

   aList := LoadList()

   DEFINE WINDOW ( xDlg ) ;
         at 0,0 ;
         WIDTH 1024 ;
         HEIGHT 768 ;
         TITLE 'modelo' ;
         ICON 'icone' ;
         MAIN ;
         NOSIZE ;
         BACKCOLOR {45,47,50}

      DEFINE TAB ( xTab ) ;
            AT 10,10 ;
            WIDTH GetProperty( xDlg, "WIDTH" ) - 20 ;
            HEIGHT GetProperty( xDlg, "HEIGHT" ) - 20 ;
            VALUE 1 ;
            HOTTRACK ;
            HTFORECOLOR BLACK ;
            HTINACTIVECOLOR GRAY

      FOR EACH aItem IN aList

         PAGE aItem[1] image 'img_3'

            @ 100, 010 LABEL ( "lbl" + Str( aItem:__EnumIndex() ) ) VALUE aItem[2] width 500 transparent bold

            DEFINE EDITBOX ( "get" + Str( aItem:__EnumIndex() ) )
               PARENT ( xDlg )
               COL 010
               ROW 120
               WIDTH GetProperty( xDlg, "WIDTH" ) - 40
               HEIGHT GetProperty( xDlg, "HEIGHT" ) - 200
               FONTNAME "Lucida Console"
               FONTSIZE 10
               VALUE MyLoadResource( aItem[3] )
            END EDITBOX

         END PAGE

      NEXT

      END TAB

      ON KEY ESCAPE ACTION DoMethod( xDlg, "RELEASE" )

   END WINDOW

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

   (xTab)

   RETURN Nil

FUNCTION LoadList()

   LOCAL aList := {;
      { "ENV",     "Environment", "setup.env" }, ;
      { "HARBOUR", "harbour\bin\hbmk.hbc", "hbmk.hbc" }, ;
      { "FIVEWIN", "fivewin\fivewin.hbc", "fivewin.hbc" }, ;
      { "HMG3",    "hmg3\hmg3.hbc", "hmg3.hbc" }, ;
      { "HMGE",    "hmge\hmge.hbc", "hmge.hbc" }, ;
      { "OOHG",    "oohg\oohg.hbc", "oohg.hbc" }, ;
      { "X.HBP",   "jpa.hbp", "jpa.hbp" }, ;
      { "X.RC",    "jpa.rc", "jpa.rc" }, ;
      { "manifest", "exe.manifest", "exe.manifest" } }

   RETURN aList

FUNCTION MyLoadResource( cName )

   DO CASE
   CASE cName == "setup.env"    ; #pragma __binarystreaminclude "res/setup.env" | RETURN %s
   CASE cName == "hbmk.hbc"     ; #pragma __binarystreaminclude "/harbour/bin/hbmk.hbc" | RETURN %s
   CASE cName == "fivewin.hbc"  ; #pragma __binarystreaminclude "/github/fivewin/fivewin.hbc" | RETURN %s
   CASE cName == "hmg3.hbc"     ; #pragma __binarystreaminclude "/github/hmg3/hmg3.hbc" | RETURN %s
   CASE cName == "hmge.hbc"     ; #pragma __binarystreaminclude "/github/hmge/hmge.hbc" | RETURN %s
   CASE cName == "oohg.hbc"     ; #pragma __binarystreaminclude "/github/oohg/oohg.hbc" | RETURN %s
   CASE cName == "jpa.hbp"      ; #pragma __binarystreaminclude "/fontes/integra/jpa.hbp" | RETURN %s
   CASE cName == "jpa.rc"       ; #pragma __binarystreaminclude "/fontes/integra/jpa.rc" | RETURN %s
   CASE cName == "exe.manifest" ; #pragma __binarystreaminclude "/fontes/integra/resource/exe.manifest" | RETURN %s
   OTHERWISE
   ENDCASE

   RETURN ""

Pois é....
Sei lá...
Reinventar a roda....

Talvez colocar Inteligência Artificial num builder.
Muitos programadores precisam disso.
As IDEs causam isso.
A ponto dos programadores afirmarem: "esta lib tem builder próprio é bem melhor...."

É só o tradicional do harbour.
Pra adicionar uma lib, usar o hbc dela.
O que tem de tão complicado nisso, a ponto da lib inventar builder ? ou do programador precisar ajuda ?
XHarbour que o diga... tem builder adoidado.

Covném chamar atenção pra isto, tavam perguntando em algum fórum por aí.
Resource embutido no PRG.

Código: Selecionar todos

FUNCTION MyLoadResource( cName )

   DO CASE
   CASE cName == "setup.env"    ; #pragma __binarystreaminclude "res/setup.env" | RETURN %s
   CASE cName == "hbmk.hbc"     ; #pragma __binarystreaminclude "/harbour/bin/hbmk.hbc" | RETURN %s
   CASE cName == "fivewin.hbc"  ; #pragma __binarystreaminclude "/github/fivewin/fivewin.hbc" | RETURN %s
   CASE cName == "hmg3.hbc"     ; #pragma __binarystreaminclude "/github/hmg3/hmg3.hbc" | RETURN %s
   CASE cName == "hmge.hbc"     ; #pragma __binarystreaminclude "/github/hmge/hmge.hbc" | RETURN %s
   CASE cName == "oohg.hbc"     ; #pragma __binarystreaminclude "/github/oohg/oohg.hbc" | RETURN %s
   CASE cName == "jpa.hbp"      ; #pragma __binarystreaminclude "/fontes/integra/jpa.hbp" | RETURN %s
   CASE cName == "jpa.rc"       ; #pragma __binarystreaminclude "/fontes/integra/jpa.rc" | RETURN %s
   CASE cName == "exe.manifest" ; #pragma __binarystreaminclude "/fontes/integra/resource/exe.manifest" | RETURN %s
   OTHERWISE
   ENDCASE

   RETURN ""

E a propósito: se a LIB estiver na pasta ADDONS do harbour, é menos configuração ainda.
É porque LIB em ADDONS recebe o mesmo tratamento de CONTRIB, como se fosse parte do harbour.

PC Toledo

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

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

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

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

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

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

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

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