PC Toledo

Então, Itamar, até você se confundiu com isso.

Não dá pra dizer que isso é problema, mas foge um pouco da programação normal.
Na verdade nem sei se isso permite controlar melhor as coisas.... talvez sim, talvez não.

Na minigui, a maioria das coisas é VARIÁVEL PÚBLICA.
E também a OOP NÃO É OOP, é tudo através de #define (ou #command ou #translate)
Muita gente se perde nisso.
E TODA informação de TUDO, fica numa única variável linguição.

Exemplo simples:

Código: Selecionar todos

#include "minigui.ch"

DECLARE WINDOW Win_2
DECLARE WINDOW Win_3

FUNCTION Main

	LOCAL i, cForm

	DEFINE WINDOW Win_1 ;
		TITLE 'Hello World!' ;
		/*WINDOWTYPE*/ MAIN ;
		ON INIT ( Win_2.Show, Win_3.Show )

	END WINDOW

	DEFINE WINDOW Win_2 ;
		TITLE 'Child Window' ;
		/*WINDOWTYPE*/ CHILD

	END WINDOW

	DEFINE WINDOW Win_3 ;
		TITLE 'Modal Window' ;
		/*WINDOWTYPE*/ MODAL

	END WINDOW

	FOR i := 1 TO 3
		cForm := "Win_" + Str( i, 1 )
		_DefineHotKey( cForm, 0, VK_ESCAPE, hb_MacroBlock( "_ReleaseWindow('" + cForm + "')" ) )
	NEXT

	Win_2.Center
	Win_3.Center

	ACTIVATE WINDOW ALL

RETURN NIL

Esses DECLARE são invenções mais recentes por CH.

Código: Selecionar todos

   #xcommand DECLARE WINDOW <w> ;
   => ;
   #xtranslate <w> . \<p:Name,Handle,Type,Index,Title,GripperText,Height,Width,ClientHeight,ClientWidth,Col,Row,NotifyIcon,NotifyToolTip,FocusedControl,Cursor,BackColor,MinHeight,MinWidth,MaxHeight,MaxWidth,TitleBar,SysMenu,Sizable,MaxButton,MinButton,Closable,Visible,Enabled,Topmost,HelpButton,Cargo,Object\> => GetProperty ( <(w)>, \<"p"\> ) ;;
...

O DECLARE aciona um sub-conjunto de #xtranslate, que traduz o fonte OOP pra não OOP.
oWindow.Handle é traduzido pelo pré-compilador pra GetProperty( oWindow, "Handle" )
Por isso, essas coisas não funcionam em run-time, a OOP é somente no fonte, sem compilar.

Isso não existia antigamente, acho que nem na minigui original HMG 3.

O DECLARE cria muita definição pra variável usada, pra traduzir tudo que estiver no fonte pro correspondente

Código: Selecionar todos

   #xcommand DEFINE WINDOW <w> ;
	[ AT <row>,<col> ] ;
	[ ROW <row> ] ;
	[ COL <col> ] ;
...
   => ;
   DECLARE WINDOW <w>  ;;
   _DefineChildMdiWindow ( <(w)>, <row>, <col>, <wi>, <h>, <.nominimize.>, <.nomaximize.>, <.nocaption.>, <.novscroll.>, <.nohscroll.>, <title>, <FontName>, <FontSize>, <{InitProcedure}>, <{ReleaseProcedure}>, <{ClickProcedure}>, <{GotFocusProcedure}>, <{LostFocusProcedure}>, <{SizeProcedure}>, <{MaximizeProcedure}>, <{MinimizeProcedure}>, <.focused.>, <cursor>, <{interactivecloseprocedure}>, <{MouseMoveProcedure}> )

Por exemplo, Windows.Handle é traduzido pra GetProperty( _Window, "handle" )

A criação da janela chama a rotina, NÃO É CLASSE.
Acaba entrando o DECLARE aí de novo.
E a criação da janela:

Código: Selecionar todos

FUNCTION _DefineWindow ( FormName, Caption, x, y, w, h, nominimize, nomaximize, ;
      nosize, nosysmenu, nocaption, aMin, aMax, InitProcedure, ReleaseProcedure, ;
      MouseDragProcedure, SizeProcedure, ClickProcedure, MouseMoveProcedure, aRGB, ;
      PaintProcedure, noshow, topmost, main, icon, child, fontname, fontsize, ;
      NotifyIconName, NotifyIconTooltip, NotifyIconLeftClick, GotFocus, LostFocus, ;
      VirtualHeight, VirtualWidth, scrollleft, scrollright, scrollup, scrolldown, ;
      hscrollbox, vscrollbox, helpbutton, MaximizeProcedure, MinimizeProcedure, cursor, ;
      NoAutoRelease, InteractiveCloseProcedure, RestoreProcedure, MoveProcedure, DropProcedure, ;
      mdi, palette, NotifyIconDblClick, cPanelParent, panel, NotifyBalloonClick, clientwidth, clientheight )
...
   FormName := AllTrim( FormName )
...
...
   mVar := '_' + FormName
...
   k := AScan ( _HMG_aFormDeleted, .T. )

   IF k > 0

#ifdef _NAMES_LIST_
      _SetNameList( mVar , k )
#else
      Public &mVar. := k
#endif

      _HMG_aFormNames [ k ] :=  FormName
      _HMG_aFormHandles [ k ] :=  FormHandle
      _HMG_aFormActive [ k ] :=  .F.
      _HMG_aFormType [ k ] :=  cType
...

#ifdef _NAMES_LIST_
      _SetNameList( mVar , k )
#else
      Public &mVar. := k
#endif
...

RETURN ( FormHandle )

Novamente:
Só mostrando parte de como funciona, que é diferente de HWGUI, por exemplo.
É um estilo que condenamos, mas isso não vém ao caso, porque funciona.

Com certeza isso reduz muito as possibilidades de mudança, porque tá cada vez mais preso ao formato pré-definido.
Começaram assim, implementaram essas coisas, não vão poder descartar o modelo, pra não perder compatibilidade com fontes existentes.

Mas, como eu disse, é muito usada, e funciona.
Vira e mexe os usuários tentam usar OOP em run-time, e não funciona, é lógico.

Quanto à variável linguição, de certa forma a HWGUI também tem.
Aqueles CLASSVAR nas classes, acaba sendo uma linguiça, que não chega a ser linguição.

Ao reduzir o fonte, parece que este bloco está repetido no fonte:

Código: Selecionar todos

#ifdef _NAMES_LIST_
   _SetNameList( mVar , k )
#else
   Public &mVar. := k
#endif

Tudo bem também, chamou a atenção estar repetido, mas aproveitei pra destacar o PUBLIC que mencionei.
Cada janela é uma variável pública.

Tem o lado bom....
Num ambiente multithread, podemos ter várias miniguis, uma em cada thread, com funcionamento isolado, e com suas próprias variáveis PUBLIC.

Código: Selecionar todos

	Win_2.Center
	Win_3.Center

Essa parte do fonte é traduzida pra DoMethod( Win_2, "center" ) ou talvez DoMethod( "win_2", "center" )

&( "win_2.center" ) com certeza não funciona, porque essa sintaxe é do pré-compilador.

OOHG é diferente, ela usa OOP, mas procuram deixar com o máximo de compatibilidade com a HMG, o que pode acabar limitando, e desprezando a OOP.

Então, se formos usar OOP de LIBs open temos: GTWVG, HWGUI e OOHG (minigui orientada a objetos).
A OOHG acho que é a minigui menos usada, por incrível que pareça.

Talvez tenha faltado dizer:

Porque direcionado ao Itamar:
É que teve um post de minigui onde mencionou chamar o método.
Aqui também já teve post de usuário não entendendo porque OOP não funcionava em run-time na minigui.

Pois é.....
Já olhei muito os fontes das LIBs, pra entender o funcionamento antes de começar a usar.
Antigamente não tinha essa parte "OOP", dá pra dizer que foi coisa de gênio, só não sei dizer se foi para o bem ou para o mal, porque dá um nó na cabeça dos usuários, que querem usar em run-time e não podem.

Olá!
Talvez a má concepção da Minigui, resultou até no abandono de mantenedores depois que entende como funciona.
Eu mesmo entendi um pouco, pq sei como fizeram mas achei até mais difícil do que OOP.

No caso seria tudo FUNÇÕES e Code Blocks.

Saudações,
Itamar M. Lins Jr.

Itamar M. Lins Jr. escreveu:Talvez a má concepção da Minigui, resultou até no abandono de mantenedores depois que entende como funciona.

Pera lá, que não é bem assim.

Existe a minigui original, a HMG 3, que antes era mantida pelo Dr. Claudio Soto, depois foi pro github, tá devagar quase parando
https://github.com/HMG-Official/HMG

Existe a HMG Extended, também chamada minigui, continua sendo mantida como sempre foi, quase todo mês tem versão nova, os fontes vém do além para o site.
última versão 2022.09.15, o download inclui os fontes.
https://www.hmgextended.com/

Existe a OOHG, continua sendo mantida como sempre foi, está no github, última atualização ONTEM. Ela é dividida em alguns repositórios.
https://github.com/oohg

HMG 3 - minigui original
HMG Extended - minigui com mais recursos
OOHG - minigui orientada a objeto

E, se não me engano, tem outras variações menos conhecidas, uma no source-forge, e parece que tem outra na China, que chegaram a mencionar num fórum.

Uma coisa que também confunde é que existe outra lib minigui, que não tem nada a ver com Harbour, é uma mini-lib pra usar GUI.

Só comentário adicional:

Uma das últimas atualizações da HMG 3 foi sobre multithread, após comentários aqui no fórum.
Rapidamente HMG Extended e OOHG incorporaram algo sobre multithread.
As 3 versões estão em uso, e cada uma tem fórum próprio e também tem fóruns mixados.

O download primário é Harbour + BCC 5.8

Bom dia!

Pois é, e no meu caso, mero mortal, que não disponho desse acervo de conhecimento e expertise... passo as vezes dias pra entender a relação entre um determinado bloco de código e o seu diferente resultado em run-time... (o resultado está certo, diferente é a minha ideia do que ele deveria apresentar....)

Uso esse: https://hmgextended.com

Uma das coisas bem estranhas (entre outras) é o fato das linhas abaixo não gerarem o resultado que, intuitivamente, deveria dar:

Código: Selecionar todos


// Estou em um Form_xxxxx

DoMethod("Form_Main","SetFocus")   // Mando o foco para esse Form

Do Events  // Nem precisaria disso, mas tentei pra ver se resolveria.....

FormAtual=ThisWindow.name   //  <-- Aqui gera o erro

MsgBox("Form Atual = "+FormAtual)   // Nem chega aqui...

Erro gerado:

Código: Selecionar todos

Error MGERROR/0 Window: _tela_ver is not defined. Program terminated.

O Form_Main não possui nada de eventos ON GOTFOCUS e nem o Formulário que estou possui ON RELEASE ou algo do gênero...

Esse erro se dá pq eu estou em um formulário que foi criado numa função que estava dentro do Formulário "_tela_ver" o qual já foi dado um RELEASE e apagado da memória, pois não é mais necessário, era apenas um Form tipo um InputBox melhorado. Se eu não der Release nesse formulário daí não gera o erro, tudo bem, MAS IGUAL não deveria ser esse o ThisWindow.Name pois o foco está em Form_Main e eu estou em Form_xxxxx.

Olá!
Quando eu escolho uma ferramenta, eu verifico se tenho como acessar o criador da ferramenta ou o grupo de usuários avançados dela.
Independente da "MARCA" ou patrocinador dela.
Neste caso ai seu eu iria para o grupo internacional dessa Minigui perguntar como fazer, se tem como fazer. Mesmo que a resposta demore ou não seja possível realizar o que desejo. Isso me da um conforto, que pelo menos eu tentei resolver, descobrir como fazer.
Desse grupo de opções da Minigui, se eu fosse escolher usaria sem dúvida nenhuma a OOHG do Fernando Yurisich, tem grupo ativo que inclusive faço parte e código no git.
https://github.com/oohg

Saudações,
Itamar M. Lins Jr.

Procure esse nome do erro em todos os fontes seus e da minigui.
Parece não existir a variável e/ou form, talvez seja um nome default, a julgar pelo prefixo _.
_tela_ver

carlaoonline escreveu:Esse erro se dá pq eu estou em um formulário que foi criado numa função que estava dentro do Formulário "_tela_ver" o qual já foi dado um RELEASE e apagado da memória, pois não é mais necessário, era apenas um Form tipo um InputBox melhorado. Se eu não der Release nesse formulário daí não gera o erro, tudo bem, MAS IGUAL não deveria ser esse o ThisWindow.Name pois o foco está em Form_Main e eu estou em Form_xxxxx.

Deixei passar o final.
Talvez esteja destruindo a variável de controle antes do formulário encerrar.

Isso de GUI é uma parafernália "por trás das câmeras", é como vários trechos de programas rodando isolados, mas dependendo um do outro.
Não é igual console que tem começo, meio e fim.
Parte do gerenciamento disso é por conta da LIB, e sempre sobra pro usuário algum controle extra.
Mas a LIB pode deixar escapar algumas coisas.... e aí complica.

JoséQuintas escreveu:formulário que foi criado numa função que estava dentro do Formulário "_tela_ver" o qual já foi dado um RELEASE e apagado da memória, pois não é mais necessário,

Mas pera aí.... geralmente tem aquela coisa de pai e filho.
Se o formulário criado for dependente do que existe, não pode destruir o anterior.
Ou, na hora de criar precisa indicar outro "pai" pra ele.

Lembro do Itamar com um problema em progressbar da HWGUI, criado por um botão.
É que uma das opções da progressbar na hwgui é criando um form só pra ela.
O problema era esse form ficar preso ao botão, e não ao form principal.

Então.... em certos casos, fica por conta do usuário, talvez por falha na LIB.
E na HMG Extended, tem tanto #xtransform pra interpretar o fonte, e pra completar o fonte, que pode falhar.
HWGUI não é diferente nisso, e nem mesmo GTWVG.

Todo controle tem um "pai".
Geralmente as LIBs fazem isso no pré-compilador, pra deixar o mais automático possível, e livrar o usuário desse trabalho.
Só que sempre tem exceções. À medida que o usuário vai ficando mais avançado, as amarrações da LIB acabam amarrando o usuário.

Em OOP isso pode ficar mais visível no fonte, e o programador pode tomar precaução.

Exemplo:
Ao criar um button, ele vai pra onde?
Das duas uma, dependendo da LIB, pode ser na tradução do pré-compilador, usar conforme o que está no INIT WINDOW, mas pode ser em run-time, na janela que estiver aberta.
Lembro de ter visto isso em uma das LIBs, do pré-compilador fazer o trabalho, mas não lembro agora em qual foi.

Note que: janela aberta, não significa necessariamente um FORM.
Tem o caso das TABs, onde ficaria numa aba, tem o caso de um button, que NÃO pode ficar no button.

PC Toledo

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI

Ao Itamar (outros também) sobre MINIGUI