migrando HMG 3.0.35 para HMG 23.04 problemas

[jorgekruger]

Olá,

Estou migrando alguns sistemas desenvolvidos em HMG 3.0.35 e iniciando uma aplicação do zero em HMG 23.04 porém não consigo compilar um projeto,

Tentei compilar um exemplo e tenho esta falha, alguém já pegou algo assim:

Applications\ACSviewer
.
Harbour 3.2.0dev (r2304211101)
Copyright (c) 1999-2023, https://harbour.github.io/
Compiling 'ACSviewer.prg'...
Lines 24728, Functions/Procedures 24
Generating C source output to 'ACSviewer.c'... Done.
O sistema não pode encontrar o caminho especificado.

C compile error.

Pressione qualquer tecla para continuar. . .

[jorgekruger]

Resolvido, era o local do BCC no arquivo bacth.bat.

[Mario Mesquita]

Boa tarde a todos.

Não achou interessante migrar para as novas versões do HMG? Está na 3.5 agora.

Alguma vantagem na HMGE?

Saudações,
Mario.

[JoséQuintas]

Por coincidência, acabei de baixar e desistir.

Só esta mudança, pra mim é o máximo.

HMG3

Código: Selecionar todos

#xcommand DEFINE WINDOW <w> ;
...
_DefineWindow ( <"w">, <title>, <col>, <row>, <wi>, <h>,...

HMG Extended

Código: Selecionar todos

   #xcommand DEFINE WINDOW <w> ;
...
=> ;
   _DefineModalWindow ( <(w)>, <title>, <col>

Não sei se depende só disso no CH.
Funciona algo normal no harbour:

Código: Selecionar todos

FOR EACH oWindow IN aList
   DEFINE WINDOW (oWindow) ...

Não era assim das outras vezes que testei.

[Mario Mesquita]

Oi, Quintas.

A HMG me atende bem, as outras nunca tive contato. Na éopca pensei em comprar aquela do espanhol mas testei a Minigui e resolveu pra mim...

Sds
Mario.

[JoséQuintas]

Dê uma olhada no meu projeto atual, apesar de ser de principiante, tem algo interessante:

https://github.com/JoseQuintas/dlgauto

Pode COMPILAR usando:

HWGUI
HMG Extended
OOHG
GTWVG

Na maior parte, os fontes de cada lib estão em LIB_xxxx.prg, pode ser uma referência básica entre as LIBs.

Foi minha forma de ter paciência pra mexer com GUI.
Executa tudo automático a partir dos DBFs, e permite configurar pesquisa entre DBFs, validação e browse.
Conforme vou aprendendo vou adicionando algo de alguma LIB.

Até ia acrescentar HMG3, mas por conta do que mencionei não deu.

Estou apenas aprendendo cada LIB, e procurando fazer a mesma coisa com elas.
Durante o processo acabei chegando nessse formato de poder testar todas de uma vez, e isolar a maior parte dos fontes de cada uma.
Mas é isso mesmo: compilar com qualquer LIB e ver tudo funcionando do mesmo jeito (ou quase tudo).

[JoséQuintas]

Decidi brincar também com HMG3.
Olhe lá.

O que o usuário faz num caso desses ?
Olhar fonte de LIB ?

Quem está acostumado não enxerga mais isso.

Tudo bem, é que por causa daquele CH isso é passado como string, e a função tenta fazer um PUBLIC &var, e por isso dá erro.

Era só passar a variável.
E agora que fizeram na HMG Extended, tá mais visível que a possibilidade PODE existir.
Fica "mais harbour", mais a linguagem de programação em uso.

A LIB é excelente, tanto que copiaram pra outras, mas detalhes assim pra mim fazem muita diferença.

Vou começar alterando os CHs igual fizeram na HMG Extended pra ver até onde vai.

[JoséQuintas]

Uia

Alterei aquele "w" para (w) no ch, igual HMG Extended.
E relacionados, por exemplo:

Código: Selecionar todos

#xcommand DEFINE MAIN MENU [ OF <parent> ] ;
=>;
_DefineMainMenu( <"parent"> )

pra

Código: Selecionar todos

#xcommand DEFINE MAIN MENU [ OF <parent> ] ;
=>;
_DefineMainMenu( <(parent)> )

o parent sem as aspas.
Agora funciona uma variável qualquer.

Se há vários anos, eu soubesse que era fácil assim resolver, talvez estivesse usando.
Mas vamos ver até onde vai, por enquanto é apenas o menu.

[JoséQuintas]

Caso goste da idéia, convém alertar:
CH de label não alterei ainda, então está tentando procurar ( oDlg )

Outra necessidade, que no meu caso tá resolvido, é que a variável precisa conteúdo.
Não adianta passar oDlg, a variável precisa ter o nome do form pré-definido.

Não é um trabalho fácil, e com certeza perde compatibilidade com fontes anteriores.
Mas quanto mais demorar pra alterar isso, mais fontes incompatíveis vão existir, e cada vez mais difícil mexer.

[JoséQuintas]

Comentário extra:

É por isso que eu tento contribuir pra LIBs.
Se não atualizar na LIB, todo esse trabalho vai pro lixo depois.
Mas vai da LIB.... Da última vez que tentei contribuir pra HMG demoraram um ano pra responder, já tinha ido tudo pro lixo.

[ivanil]

Ola Quintas;

Esquece um pouco a Macro da forma como vc atualmente a conhece;

em Define window (oDlg) simplesmente altere para Define window &(oDlg)

Não ha nada a ser consertado na lib neste quesito, é apenas entendimento. Agora tem um detalhe, se você começar a mexer no comportamento dos includes tera os efeitos colaterais como consequência; a Minigui funciona bem com variáveis, o simbolo "&" é utilizado pelo pre-processador; compile com /P e olhe os ppos parar melhor entendimento.
At.

Ivanil

[JoséQuintas]

Na HMG Extended já modificaram.
Só continua assim na HMG3.
Aqui tá tudo ok com as alterações, por enquanto.

a Minigui funciona bem com variáveis, o simbolo "&" é utilizado pelo pre-processador

Acho que não é bem assim. Acaba criando com o nome "&xxx" e chega a acusar que o controle já foi criado.

O trem tá muito doido:
Estou compilando e executando com qualquer destas: HWGUI, HMG 3, HMG Extended, OOHG, GTWVG

Só na HMG3 é que mexi nos arquivos CH.
Nas demais, tudo original.

Agora acrescentei o nome da LIB nas telas, senão nem sei mais o que estou testando kkkkk
Como eu disse, o trem tá muito doido.
MESMOS FONTES PRA TODAS. (exceto 1 específico de cada)

Nota: não era essa a intenção inicial, mas nas mexidas em fonte acabou acontecendo isso de poder usar todas.

[ivanil]

Na HMG Extended já modificaram.

Nada foi modificado neste quesito.

Acho que não é bem assim. Acaba criando com o nome "&xxx" e chega a acusar que o controle já foi criado.

Você esta tentando usar diferente da forma que mencionei...

Para dar um nome "sendo variavel", use a forma abaixo:
Define window &(odlg)

O pre processador vai criar uma definição em tempo de execução com a seguinte definição;
Declare window &(odlg) (Nota: você pode entender melhor isso olhando o include)

a partir dai o pre-processador trata toda a sintaxe corretamente.

&(odlg).textbox01.value := "teste"

Ou

x:= "textbox01"
&(oDlg).&x.value :="teste"


Isso expande as ideias, porque agora você sabe que pode chamar qualquer controle de qualquer modulo, atribuir,etc... simplesmente declarando a janela no topo, parecido com o Delphi/lazarus.

[JoséQuintas]

Que parte não entendeu?
Já mostrei que está modificado na HMG Extended.
E fiz igual na HMG3.

Na HMG Extended, os CH estão usando variável, e na HMG3 estão usando o nome.
Estavam.... modifiquei.

HMG Extended, note todas as definições de <w> para <(w)>

https://github.com/JoseQuintas/hmge/blo ... _window.ch

HMG 3, note que alterei tudo
era de <w> para <"w">
agora é igual HMG extended

https://github.com/JoseQuintas/hmg3/com ... 2aa3348fc9

Se a definição transforma em texto, não tem macro que resolva.

Se não vai ter compatibilidade com fontes anteriores, pra mim não importa, não tenho fontes anteriores.

Está funcionando lindamente.
Só tenho coisas pra resolver, mas tudo bem, algum dia encontro alguma solução.
browse não tinha exemplo em lugar nenhum, mas encontrei exemplo de grid.
não encontrei exemplo de textbox multilinha.
essas coisas básicas.

[JoséQuintas]

Até agora tudo ok.

O que aconteceu de diferente é que precisava uma solução pra BROWSE na HMG Extended, e serviu a solução da HMG 3 com GRID.
E na HMG Extended, olhando pelo manual não tem as opções no GRID.
Olhando no manual não tem, mas elas continuam funcionando.

Não achou interessante migrar para as novas versões do HMG? Está na 3.5 agora.
Alguma vantagem na HMGE?

Sobre isso, não sou usuário ativo, mas dá pra dizer.

HMG 3 mudou o número de versão, mas não teve mudança nenhuma até hoje.

HMG Extended recebeu controles novos, o mais comentado é o TSBROWSE, com o mesmo funcionamento do FIVEWIN.
O mais comum é ter versão nova todo mês, com melhorias e eventuais correções.
O post menciona HMG Extended 23.04 e a atual é 23.09, pode-se dizer que uma era de abril, e a atual é de setembro.

Mas de um modo geral, não se altera o aplicativo só porque a LIB mudou, a não ser que a novidade seja interessante, ou se for pra corrigir algum problema existente. O mesmo vale pra trocar de LIB, ou trocar harbour/xharbour, compilador C, etc. aonde também pode entrar alguma preferência pessoal, ou até o simples fato de seguir o que a maioria usa, independente de qualquer outra coisa.