PC Toledo

Eu também ajudaria, porque tudo que faço aqui vou perder ao atualizar.

Tem lugar que está _HMG_SYSDATA, tem lugar que está _hMG_SYSDATA
#define não tem efeito se estiver diferente.

Me refiro a ajudar apenas na formatação de fontes.
Só de formatar já vai mostrar como muita alteração.
Nesse momento é melhor não mexer em mais nada, senão qualquer alteração vai ficar escondida no meio disso, e vai ser difícil localizar alguma coisa no caso de eventual problema.

Até mesmo alteração pra -w3 -es2 é melhor deixar pra depois da formatação, porque vai precisar de ajuste adicional em alguns casos.

github eu estou acostumado, só ainda não conheço o lado de quem recebe alterações, quando precisa ajuste pra integração de commits.

No caso da alteração básica pra multithread, as 6 linhas:
Não existe mais variável pública, e não precisa mais ficar declarando variável em todos os fontes.
Dessa forma fica visível em multithread, acho melhor que HB_THREAD_INHERIT_PUBLIC, porque não mexe com outras coisas que possam existir no aplicativo.

inexplicavelmente, somente em HMG ainda não funciona.

Código: Selecionar todos

Error on 02/14/17 09:59:53
Alias:  
Folder: d:\CVSFiles\hmgall\hmg\SAMPLES\Basics\Hello_World\
Windows: Windows 10 10.0
Computer Name: JOSEJPA
Windows User: joseq
Logon Server: \JOSEJPA
User Domain: JOSEJPA
Harbour: Harbour 3.4.0dev (21d13913d5) (2017-02-04 12:47)
Compiler: MinGW GNU C 5.3 (32-bit)
GT: WVG



Error BASE/1068  Argument error: array access
Called from _DEFINEWINDOW(4043)  
Called from TESTHMG(22)  
Called from (b)MAIN(9)

Não consigo entender.
Mesma variável, mesmo esquema, funcionou em OOHG, HMG Extended, mas ainda falta algum detalhe em HMG.
Talvez algum MEMVAR que falta remover, ou algo assim.

Alterei pra só trocar o nome da variável:

Código: Selecionar todos

#define _HMG_SYSDATA __HMG_SYSDATA
MEMVAR __HMG_SYSDATA

Em h_init.prg, deixei o PUBLIC

Código: Selecionar todos

   PUBLIC __HMG_SYSDATA := Array(518)

Ou seja, o CH só troca o nome da variável, e continua tudo como antes.

Error BASE/1003 Variable does not exist: __HMG_SYSDATA
Called from _DEFINEWINDOW(4043)
Called from MAIN(23)

É como se o Init() não estivesse sendo executado.
Neste caso é sem multithread, é HMG do jeito que sempre foi, apenas alterando o nome da variável.
o PUBLIC está com 2 underlines, e a mensagem de erro também.
Mistério....

A propósito...
A errorsys da HMG não serve pra erros da HMG.
Se HMG não funciona, como usar a própria HMG pra mostrar erro?... rs
Mais um motivo pra ter uma errorsys padrão, sem depender de biblioteca.
Basta registrar o erro em hb_out.log e abrir no bloco de notas.
Funciona sempre: não depende nem de console e nem de GUI

Aqui dá uma idéia interessante.
Basta eu abrir o fonte no meu editor de textos e salvar - Programmers Notepad.
Ele remove espaços em branco inúteis.
Fontes menores, menos espaço em disco, e download mais rápido.

Como reinstalei HMG.... voltaram todos.
Significa que seria melhor se eu pudesse salvar no oficial esse tipo de alteração.

(ele não mexe em espaços internos do fonte, somente espaços em branco no final da linha, linhas em branco extras no final do fonte )

Una sugerencia, cambiar el #define por
#xtranslate _HMG_SYSDATA => _HMGApp()

esto eliminaría los problemas de may y minúsculas en el nombre.

En HMG OFICIAL hay otras variables públicas que yo he creado tal vez por eso no funciona adecuadamente, tengo como tarea pendiente incluirlas en _HMG_SYSDATA y cambiar el nombre de la var pública en cuestión por un #translate que haga referencia a la posición apropiada de _HMG_SYSDATA

Otro problema con MT en un lenguaje como C son las variables estáticas, generan el mismo problema que las variables públicas porque son direcciones de memoria compartidas, si dos thread llaman la misma función estas puden escribir al mismo tiempo en la variable estática y el resultado es impredecible. Pero Hb es un mundo aparte, los threads aislan las variables públicas, las clases se implementan mediante funciones, etc y todo lo fantástico o espantoso que se pude hacer con una MV, en fin tiene cosas que solo se ven en Hb.
Como leí alguna vez en un post de Maligno, algo así como: no se ofendan con migo pero no uso Hb y odio quien usa, si quieren aprender a programar en un lenguaje de verdad aprendan C, jajaja

Una sugerencia, cambiar el #define por
#xtranslate _HMG_SYSDATA => _HMGApp()

Pensei nisso, mas a idéia seria justamente já fazer os acertos nos fontes.

En HMG OFICIAL hay otras variables públicas

São apenas testes. Dependendo do rumo dos testes é que se decide como alterar os fontes.

si dos thread llaman la misma función estas puden escribir al mismo tiempo en la variable estática y el resultado es impredecible

Pra tudo há uma resposta.
A questão maior é: Compensa todo trabalho. Se compensar, criamos uma forma de fazer isso.
Quando mexe no array? Na criação de uma janela? mutex na criação da janela poderia ser uma possibilidade.

Poderiam ser usadas classes/OOP.
Isso seria excelente, mas desde que exista uma IDE que trate/confira isso.
Sem validação do que está sendo digitado, pode se tornar mais perigoso até do que variáveis públicas.

Encontrei até coisas interessantes no meio dos fontes das LIBs.
Não que seja certo ou errado, mas interessantes.
Por exemplo OOHG:

Código: Selecionar todos

#xtranslate _OOHG_ActiveControlInfo  => _OOHG_AllVars \[   1 \]
#xtranslate _OOHG_ActiveFrame        => _OOHG_AllVars \[   2 \]
#xtranslate _OOHG_AdjustFont         => _OOHG_AllVars \[   3 \]

À primeira vista, isso tem vantagens

- Facilita entender fonte
- Evita erros, compilando com o uso de -w3 -es2
- Acaba permitindo alterar vários fontes de uma vez, apenas alterando o CH, para testes eventuais ou algo definitivo.

Mas é curioso. Apesar de sugerir que tudo é OOP, acaba parecendo mais maquiagem de fonte, no fundo todas as HMG usam a mesma coisa, a variável pública.

Essa é uma parte ruim no mundo xbase, tem variações demais, na maioria das vezes código copiado, que espalha cada vez mais os usuários xbase.
Talvez uma diferença no C seja esta: a sintaxe é sempre padrão e obrigatoriamente o programador cria sua própria biblioteca de rotinas.
Isso obriga o programador a pensar no que é melhor pra ele, sem sair do padrão da linguagem.

Eu só sei o seguinte: é o que temos
Deixar fontes formatados é interessante, não tem sentido fazer em minha máquina, porque ao atualizar vou perder tudo.
Seria interessante, pelo menos essa parte, deixar centralizado.
Já é diferente do que a maioria faz, que é apenas copiar o que existe, com erro e tudo, e nem sequer formatar/corrigir fonte.

Sobre o que eu sugeri de formatar fontes.
Não serve o hbformat, vai ter que ser feito manualmente, um por um.

Por mim, formato o fonte de todas as LIBs: OOHG, HWGUI, HMG e HMG Extended.
Mas se não for pra atualizar o original, não compensa, porque é perder tudo numa próxima atualização.

Por enquanto dá insegurança usar os fontes do jeito que estão, infelizmente.... mas neste caso por causa da compilação -w3 -es2 que seria a etapa seguinte.

Exemplo de fonte que precisa ser formatado: tprint.prg

Código: Selecionar todos

DATA impreview          INIT .F. PROTECTED
DATA cversion            INIT "V1.2" PROTECTED

*-------------------------
METHOD init()
*-------------------------
*-------------------------
METHOD begindoc()
*-------------------------
*-------------------------
METHOD enddoc()

method printdos()
*-------------------------
*-------------------------
METHOD beginpage()
*-------------------------

METHOD condendos()

METHOD NORMALDOS()

*-------------------------
METHOD endpage()
*-------------------------
*-------------------------
METHOD release()
*-------------------------
*-------------------------
METHOD printdata()
*-------------------------
*-------------------------
METHOD printimage
*-------------------------
*-------------------------
METHOD printline
*-------------------------

METHOD printrectangle
*-------------------------

METHOD selprinter()
*-------------------------
*-------------------------

METHOD getdefprinter()
*-------------------------

*-------------------------
METHOD setcolor()
*-------------------------

*-------------------------
METHOD setpreviewsize()
*-------------------------

*-------------------------
METHOD setunits()   ////// mm o rowcol
*-------------------------

METHOD printroundrectangle()

METHOD version()  INLINE ::cversion

ENDCLASS

para isto:

Código: Selecionar todos

DATA impreview          INIT .F. PROTECTED
DATA cversion            INIT "V1.2" PROTECTED

METHOD init()
METHOD begindoc()
METHOD enddoc()
method printdos()
METHOD beginpage()
METHOD condendos()
METHOD NORMALDOS()
METHOD endpage()
METHOD release()
METHOD printdata()
METHOD printimage
METHOD printline
METHOD printrectangle
METHOD selprinter()
METHOD getdefprinter()
METHOD setcolor()
METHOD setpreviewsize()
METHOD setunits()   ////// mm o rowcol
METHOD printroundrectangle()
METHOD version()  INLINE ::cversion

ENDCLASS

Exemplo de fonte que precisa correção -w3 -es2
h_report.prg, faz parte da LIB básica da HMG

Código: Selecionar todos

METHOD leadatologic(cName,cPropmet,cDefault) CLASS _HMG_REPORT
local i,sw
sw:=0
For i:=1 to HMG_LEN(repobject:aline)
if HB_UAT(HMG_UPPER(cname)+' ',HMG_UPPER(repobject:aline[i]))#0   
   sw:=1
else
   if sw==1
      if HB_UAT(HMG_UPPER(cPropmet)+' ',HMG_UPPER(repobject:aline[i]))>0
         return .T.
      endif
      if HMG_LEN(TRIM(repobject:aline[i]))==0
         i=HMG_LEN(repobject:aline)+1   // <<-------------- pra que raios deve servir isto? será erro?
         return cDefault
      endif
   endif
endif
Next i
return cDefault

Então uma primeira etapa seria apenas formatar os fontes, pode ser que as outras coisas fiquem mais claras.
Uma segunda etapa, que pode precisar atenção de quem conhece bem a HMG, seria acertar pra ser compilado com -w3 -es2.
Só depois disso dá pra pensar em alterar alguma coisa, mas não é essa minha intenção pra oficial, porque não tenho conhecimento pra isso ainda.

Se quiser ajuda nisso aproveite agora, porque se eu mexer em outras coisas, meus fontes não servirão mais pra atualizar a oficial.

Tinha me esquecido de olhar a IDE.
Não sei se já avisaram, mas no Windows 10 com monitor 4k é problema.
A janela de código fonte fica pequena, sem opção de redimensionar.

Ao mesmo tempo, o Windows 10 faz redimensionamento no que for padrão, causando deformação e até dificuldade de leitura dos textos

É só comentário, talvez ainda não tenham avisado sobre isso.

Uma duvida:

Pelo que entendi, h_rtpgen.prg é relatórios, uma espécie de gerador.

Ele também usa a tal variável pública, pra guardar suas definições.

Código: Selecionar todos

Procedure _DefineReport ( cName )

	_HMG_SYSDATA [ 206 ] := Nil
	_HMG_SYSDATA [ 207 ] := Nil

	_HMG_SYSDATA [ 118 ] := 0
	_HMG_SYSDATA [ 119 ] := 0

Mas... o que acontece se forem gerados dois relatórios simultâneos?
Tenho a impressão de que o uso da variável pública é exagerado, e a própria HMG já tem suas limitações de uso simultâneo, independente de multithread.

Nota:

Estou fazendo apenas uma pequena alteração inicial.
Em i_var.ch acrescentei MEMVAR _HMG_SYSDATA
Como praticamente todo fonte tem #include "hmg.ch", que por sua vez tem #include "i_var.ch", isso vai acrescentar a declaração, inclusive em fontes de usuário, o que é bom.
Agora removendo isso de todos os fontes aonde acusa duplicidade de declaração.
E foi por isso que o fonte acima chamou minha atenção, mesmo sem usar componente windows, usa muito o _HMG_SYSDATA.

Sim, já tinha feito tudo isso antes, mas devido a um comportamento estranho, zerei tudo e estou fazendo novamente passo a passo.

Inclusive acho que seria interessante agrupar todas as declarações de variáveis públicas da HMG nesse i_var.ch

JoséQuintas escreveu:usa muito o _HMG_SYSDATA

Tanto HMG como Minigui Extended também. A Extended é ainda maior...

Sim, mas me refiro ao exagero, que seria melhor pensar em outra alternativa.
Tentando explicar esse:

Você tem um relatório, ele precisaria de variáveis:

Código: Selecionar todos

aTitulo := {}
aColunas := {}
nLinha := 5
nColuna := 10

O que a rotina faz: pro usuário não precisar declarar as variáveis no fonte, usa a variável pública

Código: Selecionar todos

_HMG_SYSDATA[ a ] := {}
_HMG_SYSDATA[ b ] := {}
_HMG_SYSDATA[ c ] := 5
_HMG_SYSDATA[ d ] := 10

Mas sendo assim, dois módulos de relatório ao mesmo tempo poderia ter resultados imprevisíveis, porque seriam misturadas as informações dos dois relatórios.

Nesse caso a variável pública, que é um controle importante da HMG, foi usada pra guardar valores temporários.

Isso causa uma situação esquisita: Usar um ambiente multijanelas, mas limitado a uma janela.

Não sei se acontece em outros lugares.

Ok, vai ser difícil o usuário pedir mais de um relatório de uma vez, mesmo se for um relatório demorado
Mas poderia até ser uma variável PRIVATE no módulo, deixando tudo mais independente.

Lembrando que não estamos falando de um "programinha", e sim de uma biblioteca.
Uma biblioteca precisa ter muito mais cuidado com essas coisas.

Não tinha pensado nisso antes, mas está aí um erro grave da HMG.
Errorsys.
Se é usado ambiente visual pras mensagens de erro..... e HMG não funciona em multithread.... como ela vai mostrar o erro em multithread?

A melhor opção é sempre gravar em disco e abrir no bloco de notas.
De preferência no arquivo padrão do Harbour HB_OUT.LOG

Experimente esta:

https://github.com/JoseQuintas/AllGui/b ... RORSYS.prg

Não parece, mas faz muita diferença.
Principalmente para o Dr Claudio Soto, que fazendo testes fora do normal deve acabar ficando sem mensagens de erro da HMG.

La verdad José que nunca uso el error sys de HMG siempre utilizo el de HB, a nivel de c uso HMG_Trace, bt_MessageBox o algún título de alguna ventana para inspeccionar el contenido de alguna variable o puntero. Yo arranque como desarrollador en 2012 y la mayoría de las cosas ya venían hechas de mucho tiempo atrás (HMG nace en 2002) y a veces cambiarlas no es tan fácil sin desarreglar alguna otra cosa, además yo le di más importancia al desarrollo de la parte en c del API de Windows que a nivel prg. Mi visión fue siempre que HMG se pegase lo más posible al SO y se hiciese un uso extendido del API, eso da más flexibilidad y facilidades al programador.

además yo le di más importancia al desarrollo de la parte en c del API de Windows que a nivel prg. Mi visión fue siempre que HMG se pegase lo más posible al SO y se hiciese un uso extendido del API, eso da más flexibilidad y facilidades al programador

Entendo, até fico na dúvida se as rotinas em C ficariam melhores agrupadas numa LIB Windows, ou cada uma no controle para o qual foi destinada.

Mas acho que o ideal seria tentar reduzir a necessidade de C por parte do usuário.

Por favor, veja este post com atenção.

https://pctoledo.org/forum/viewto ... 43&t=18080

PC Toledo

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG

Pedidos pra HMG