PC Toledo

Viktor está trabalhando muito nas LIBs Windows.

No meu ponto de vista, ele tá movendo tudo que é API windows pra dentro da hbwin, por etapas:
- Ele dá uma geral na LIB, criando funções temporárias compatíveis
- Deixa essas funções prontas pra embutir na hbwin
- Depois incorpora na hbwin
- Se já existir, também faz por etapas

A hbwin ganhou muitas funções.
E muitas funções repetidas foram eliminadas.
Além disso, a lista de funções e manuais (quando disponíveis) foram padronizados e incorporados ao hbmk2.

Eu tinha um fonte agrupando várias funções da API do Windows, e eliminei várias porque passaram a fazer parte da hbwin.

Quem sabe não está aí uma boa oportunidade de reagrupar as duas versões do Harbour.

No final vai ficar assim mesmo.
Todas as duas usam WAPI do windows.
Se fosse no LINUX seria impossível.
No Linux tem QT,KDE,GNOME... todas são "desenhadoras de janelas" no Windows só tem a WAPI mesmo!! para quê mais de uma WVG, WVW... basta uma.
Agora a WVT ele não vai mexer muito porque é usada no LINUX.
Acredito que pode até unificar a WVG e a WVW.

Saudações,
Itamar M. Lins Jr.

Isso pode causar uma revolução em outras LIBS.
A HWGUI e a Minigui podem deixar de exitir, também. Já que elas são apenas uma "CASCA" em C p/ podermos chamar as WINDOWS,DIALOGS,BUTTONS, etc...

Veja por exemplo na HWGUI o fonte em C para criar uma Janela "WINDOW" e que na MINIGUI é a MESMA coisa.

Código: Selecionar todos

      if( RegisterClass( &wndclass ) )
      {
         hWnd = CreateWindowEx( ExStyle, lpAppName, lpTitle,
               WS_OVERLAPPEDWINDOW | nStyle,
               x, y,
               ( !width ) ? ( LONG ) CW_USEDEFAULT : width,
               ( !height ) ? ( LONG ) CW_USEDEFAULT : height,
               NULL, NULL, ( HINSTANCE ) hInstance, NULL );

         temp = hb_itemPutNL( NULL, 1 );
         SetObjectVar( pObject, "_NHOLDER", temp );
         hb_itemRelease( temp );
         SetWindowObject( hWnd, pObject );

         aWindows[0] = hWnd;
      }

Código: Selecionar todos

  * contrib/hbwin/wapi_winuser.c
    + WIN_HWND_BROADCAST constant
    ! hbwapi_par_WPARAM(), hbwapi_par_LPARAM() macros fixed
      to accept both pointer and numeric without an RTE
    + new WAPI functions:
      wapi_CallWindowProc()
      wapi_DefWindowProc()
      wapi_PostMessage()
    ! WAPI_CREATEWINDOWEX() fixed to accept valid numeric input for hMenu parameter
    + wapi_AppendMenu(), wapi_InsertMenu() disable item type autodetection
      for items marked manually as separator

  * contrib/gtwvg/legacy.c
  * contrib/gtwvg/paint.prg
  * contrib/gtwvg/wvgwin.c
    * mapped more GTWVG functions to WAPI:
      WVG_CALLWINDOWPROC() -> WAPI_CALLWINDOWPROC()
      WVG_CREATEWINDOWEX() -> WAPI_CREATEWINDOWEX() (slightly different defaults)
      WVG_DEFWINDOWPROC()  -> WAPI_DEFWINDOWPROC()
      WVG_POSTMESSAGE()    -> WAPI_POSTMESSAGE() (will do UNICODE conversion for strings)
    * wvg_SetWndProc() rewritten as WAPI wrapper

  * contrib/gtwvg/wvgwing.c
    ! fixed recent warning

Repare que todas usam a mesma "COISA" a tal função da WAPI do OS WINDOWS, CREATEWINDOWEX()

Saudações,
Itamar M. Lins Jr.

Isso seria muito bom, ao invés de mais e mais GUIs, talvez mais e mais controles.
Mas acho difícil, porque além dos controles tem a parte gerencial deles, e isso acho que não é padrão, e não sei se dá pra usar totalmente as APIs do Windows pra isso.

Penso em outra coisa há algum tempo: ter um único controle central básico estilo Windows, um controle de usuário.
A partir desse, o usuário poder criar à vontade.

Se imaginar que o cmdButton é uma janela com desenho/texto, e temos funções de fazer isso, precisaríamos só do controle de usuário, com eventos disponíveis, e o resto nós mesmos poderíamos fazer.
Isso deixaria aberto pra controles ilimitados, com aparência ilimitada.
Quem sabe pelo menos esta parte esteja se aproximando...

Amiguinhos,

Assim como temos editores de textos aos montes, cada um com recursos diferenciados, mas o intuito é editar texto, tenho pra mim que as bibliotecas gráficas deverão se adaptar ao Harbour de forma transparente afim de manter o público que já as usa.

Senão haverá uma debandada e insatisfação pelo tempo despendido em usá-las na codificação.

Cada uma tem sua sintaxe e muitos se acostumaram a cada uma. Vamos continuar torcendo para a compatibilidade final.

E pensando bem, esquecemos algo importante: todas elas já usam as APIs do Windows.
Centralizar as APIs do Windows no Harbour não as deixa compatíveis, senão elas já seriam compatíveis antes.

Trabalhar direto em API do Windows exige muito código, então cada LIB tem suas facilidades, cada uma de um jeito.
A única forma de integrar seria criar estas "facilidades" dentro do Harbour.
Talvez aqui esteja no motivo de estarem separadas.

A sintaxe que cada uma tem não é problema, isso é resolvido com arquivos CH, sem afastar usuários.

De qualquer forma, se for possível integrar GTWVW, GTWVT e GTWVG, isto poderá ser o começo.
Uma vez perguntei sobre o espacejamento de linhas que existe na GTWVW, se poderia ser feito na GTWVG, e a resposta foi não, porque deixaria a GT fora dos padrões pré-estabelecidos.
De repente, ao integrar todas, este recurso vai ser perdido, e isso já interfere no que já faz parte do Harbour.
E se interfere no que faz parte do Harbour, dá pra imaginar que pode interferir muito no que não faz parte...

Nota: Este espacejamento melhora na hora de fazer os retângulos dos GETs. Atualmente o efeito se perde quando se usam duas linhas seguidas, porque o espaço que sobra não é suficiente pra fazer o retângulo. Nos exemplos é pulada uma linha entre os "gets".

...se poderia ser feito na GTWVG, e a resposta foi não, porque deixaria a GT fora dos padrões pré-estabelecidos.

Penso que isso não tem nada a ver. São apenas firulas dos programadores. Uma Window é igual no Harbour/Delphi/C# a chamada da API do windows será sempre a mesma no final vai está lá a chamada em C/C++ ou Assembler, WAPI_CREATEWINDOWEX().
http://msdn.microsoft.com/en-us/library ... s.85).aspx

O que pode ocorrer é apenas o algo mais, por exemplo na WVG o padrão da barra é LILAS com título Negrito, o padrão da WVW é CINZA com título sublinhado...
A mesma coisa quando usamos uma Boa IDE que tem opções de mexer na Window com MDI sem MDI, com o _, [], X, no canto superior direito e por ai vai.
Não existe o que inventar no sistema operacional Windows, todas a linguagens irão acessar as API´s da mesma forma. Por isso a dificuldade de migrar uma aplicação visual do Windows p/ Linux, porque é totalmente diferente.
A mesma coisa é o HTML, não existe HTML do pedro, HTML do joão..., existem navegadores diferentes. As TAG´s o CSS´s são padrões, inclusive a QT e por tabela a HBQT usa a mesma sintaxe do CSS nas suas Janela, Gets, etc... uma sábia decisão e torna a HBQT muito poderosa.
Para compreender melhor e bom estudar a arquitetura universal da WINDOW suas caracteristicas.
No ambiente da M$(windows) acessamos via chamadas da API. Já no Android é via a tal Dalvik(descontinuada) usando XML!

Tanto é, que um aplicativo no windows se uma pessoa inventar que é feito em FiveWin ou Delphi ou Hwgui ou C# ou FoxPro é difícil saber só olhando as janelas e ícones.

Saudações,
Itamar M. Lins Jr.

Sim... e não.
Em termos visuais o Windows faz tudo.
Mas o controle é mais que o visual, tem rotinas acionadas conforme o que acontece.
Aqui pode entrar a parte de variáveis, área de arquivo aberta, etc.
E voltamos a parte central gerenciando tudo, que não é apenas API Windows.

Mas o controle é mais que o visual, tem rotinas acionadas conforme o que acontece.
Aqui pode entrar a parte de variáveis, área de arquivo aberta, etc.
E voltamos a parte central gerenciando tudo, que não é apenas API Windows.

Não o NT/7/8/9 é um sistema operacional que já tem a parte gráfica "misturada" com o KERNEL.
No Win98/ME podiamos instalar somente o DOS lembra disso ?
No autoexec.bat colocavamos um win.com (não lembro direito), para ir direto p/ o gerenciador de janelas...

No Linux vc instala quase tudo somente usando linha de comando(Bash e afins). Não precisamos da parte gráfica KDE/Gnome para instalar o PostGree, Apache, Squid, SAMBA, Harbour(GTWVT), etc...
A MS até cogitou de criar um Windows sem a parte gráfica.
Tudo que fazemos no Windows é LIMITADO pelo sistema só podemos fazer o que o SISTEMA GRÁFICO oferece.
Vc está misturando as funções de manutenção de arquivos/sockets com parte gráfica... Isso no LINUX é bem distinto, no Ruindows os usuários que não estão acostumados ficam ás vezes perdidos.
Tanto é que podemos instalar LINUX sem placa de video VGA, não existe a obrigação de instalar a parte gráfica que comunica com as placas de vídeo. Já com windows não é possível INSTALAR ele somente usando a LINHA DE COMANDO. Vc pode usar o Kernel mais novo do Linux e todo o poder dele com um monitor CGA!

Por isso o LINUX cresce vertiginosamente (dispositivos embarcados) as empresas usam "Gerenciadores de JANELAS" LIGTH tipo "WindowMaker", "FVWM95", "AFTERSTEP"
Todos esses eu já usei.

http://pt.wikipedia.org/wiki/Enlightenment
No Linux temos N gerenciadores de Janelas. No sistema Opercional WINDOWS temos apenas o que a MS oferece. É 1(um) só!

Para simplificar a conversa é só olhar os fontes da Hwgui, Minigui, GTWVG, GTWVW...
A sintaxe, OOP ou procedural não é um recurso destas LIBS é recurso do Harbour.
O Harbour é que permite que escrevamos.

oDlg:Activate()
ou
Activate Dialog oDlg
ou
WITH Object oDlg:=MinhaClasseDialog()
:setWindowTitle("Hello Word")
:connect(...)
END

Saudações,
Itamar M. Lins Jr.

Amiguinhos,

A MS até cogitou de criar um Windows sem a parte gráfica.

Cogitou não, existe as versões CORE, desde o Windows Server 2000. Apesar do Windows ser concebido para se utilizar sua interface gráfica ao extremo, comandar através do console dá poderes diretos num leque imenso.

Tudo que fazemos no Windows é LIMITADO pelo sistema só podemos fazer o que o SISTEMA GRÁFICO oferece.

Com certeza você quiz dizer que só conseguimos fazer o que podemos ver, se pensarmos que os resultados são somente aqueles que se mostram em telas.

Na verdade a possibilidade de configurar o Windows pelo DOS é imensa, nós é que não temos saco de digitar parametros pra-caramba para obter o resultado de um clique ou uns avançar.

No Linux eu vejo uma obrigatoriedade de uso de console pra muuuita coisa, então é questão de costume em contrapartida no Windows é só clicar, clicar e clicar, então é questão de comodismo.

Eu já não parti para o Linux devido este grandioso leque de customizações. É muita customização que se acaba por perder o caminho de qual versão é a melhor.

A facilidade de se mexer sob ou sobre um sistema operacional é de longe interessantíssima, mas como desenvolvedor gráfico a inconstÂncia da interface só prejudica o resultado final.

Eu mesmo achei a interface do Windows 8 capada, estilizada ao extremo, coisa-de-outro mundo, lembro dos tempos do DOS quando consegui fazer uma sombra nas minhas janelas onde usavamos um caracter especial conferindo sombra real, estilos as telas do Norton Tools, aquilo era o máximo.

É compreensível que cada interface gráfica tenha sua sintaxe, que se possa usar um .CH que converta/traduza a sintaxe para o programador, mas o Harbour, no inicio foi uma ponte entre programa e programador e torna-se uma ponte entre programa e interface exige demais.

Ter uma unica interface/API, como Windows, restringe o programador somente para este mundo, mas padroniza, não importando qual linguagem seja usada.

Estes divisores-de-aguas é que nos desnorteiam, é Harbour e xHarbour, Harbour do Viktor e de num sei quem, GT, QT, HB, eu mesmo já tô loco.

Os trabalhos são primorosos e todas as ferramentas criadas até o momento estão de parabéns, mas acho que ainda seja cedo pra ver uma consistência.

Eu li novamente, o que o José escreveu e entendi quando ele diz, que a nível de variáveis e controles dos objetos é um problema do criador da LIB.
Porém de uma maneira geral não precisaríamos de tantas LIB´s.

No Linux eu vejo uma obrigatoriedade de uso de console pra muuuita coisa, então é questão de costume em contrapartida no Windows é só clicar, clicar e clicar, então é questão de comodismo.

Essa obrigatoriedade eu acredito que já não existe mais. Existem configuradores variados inclusive via BROWSE´s (navegadores)

Estes divisores-de-aguas é que nos desnorteiam, é Harbour e xHarbour, Harbour do Viktor e de num sei quem, GT, QT, HB, eu mesmo já tô loco.

Rsrssrs... Teve um desentendimento deles 3 (Viktor/Midaugas/Przemek) o Viktor achou melhor fazer o fork dele. É ruim porque existe o retrabalho de ficar ajustando. Mas deu uma maior liberdade p/ ele fazer as modificações dele.
O Linux é melhor ? Eu acredito que sim por N motivos.
Mas eu ficarei no Windows até que meus clientes parem de usar. O preço que paguei para usar LINUX (bandeirante), financeiramente falando eu não tive retorno. Esse negócio de pioneirismo tem um preço.

Saudações,
Itamar Martins Lins Jr.

Sim, só verificar o que está sobrando nas LIBs.
Ainda tem muita coisa que não tem a ver com a API do Windows, mas sim com os controles internos de cada GUI.

Hoje descobri uma novidade interessante na GTWVG.
Nos botões, os ícones transparentes estão.... transparentes.
Provavelmente as mudanças do Viktor corrigiram isso.

Acabei convertendo tudo de novo de bmp pra ico.

Nota:
Por incrível que pareça, é a única coisa gráfica que uso. Só falta redimensionar automático o desenho pra completar.
Não imagino voltar esse menu pra texto, é muita coisa.

Se você ver como é fácil e poderosa a HBQT eu fiquei entusiasmado com ela.
Essa barra pode ficar solta da Window, colapsada etc... redimensionar icones usando sintaxe CSS é show!
Podemos usa BMP,PNG,ICO,JPG...
E ainda o melhor para quem gosta de desenhar usar a QT Creator!
Podemos misturar com WVG.
Usar a sintaxe Clipper PURO!

Código: Selecionar todos

METHOD SCIQT:qT_Bar()
   LOCAL oEtq, oFnd
     
   WITH OBJECT ::qTBar := ::qMainWindow:addToolBar("Opções")
      :seticonsize(QSize(48,48) )
      :setSizePolicy( QSizePolicy_Expanding, QSizePolicy_Preferred )
      :setMinimumHeight( 48 )
      :setToolButtonStyle( 3 ) 
   ENDWITH   
   oEtq := QAction( ::qMainWindow )

   oEtq:setText( "&Estoque" )
   oEtq:setIcon( QIcon( "imagens\png001.png" ) )
   oEtq:setToolTip( "Arquivo do estoque" )
   oEtq:connect( "triggered(bool)", {|w,l| FileDialog( "New" , w, l ) } )
   ::qTBar:addAction( oEtq )

    oFnd := QAction( ::qMainWindow )

   oFnd:setText( "&Fornecedores" )
   oFnd:setIcon( QIcon( "imagens\png002.png" ) )
   oFnd:setToolTip( "Arquivo de fornecedores" )
   oFnd:connect( "triggered(bool)", {|w,l| FileDialog( "New" , w, l ) } )
   ::qTBar:addAction( oFnd )
   
RETURN SELF

Saudações,
Itamar M. Lins Jr.

Agora fazendo faxina na parte de impressão.

Código: Selecionar todos

  * contrib/gtqtc/gtqtc.hbp
    * updated to new QT homepage

  * contrib/hbwin/hbwin.hbx
  * contrib/hbwin/win_prn1.c
  * contrib/hbwin/win_tprn.prg
    * replaced redundant win_* functions with wapi_* calls, and
      deprecated them with HB_LEGACY_LEVEL5 [INCOMPATIBLE]
      win_AbortDoc()
      win_CreateDC()
      win_DeleteDC()
      win_EndDoc()
      win_EndPage()
      win_FillRect()
      win_StartDoc()
      win_StartPage()
      win_TextOut()
      See the diff for details

  * contrib/xhb/xhbdepr.prg
  * contrib/xhb/xhbwin.c
    % minor cleanup (in disabled code)

Saudações,
Itamar M. Lins Jr.

Só curiosidade....
Hoje atualizei a lista de funções em harbourdoc para o Harbour 3.2.
Depois disso, atualizei para o Harbour 3.4..... Acrescentou 385, na maioria da gtwvw e hbwin.

Agora a base de dados disso subiu pra 6.344 registros, é muita função.
Apesar de misturado, aproveitei pra marcar em compliance hb32 e hb34, assim dá pra saber a qual pertence.
Usei a saída de hbmk2 -find *

No final, peguei a lista que sobrou sem indicação de nenhum dos dois e pra minha surpresa, existem várias que não aparecem nas listas.

PC Toledo

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN

GTWVW, GTWVT, GTWVG, HBWIN