GTWVW contém a solução gráfica

[Pablo César]

Por favor quem entende bem de parte gráfica leia até o final, pode ser usuário de minigui, hwgui, ou qualquergui...

Estou pra postar uma sugestão no fórum de desenvolvedores, é teórica, mas me parece ser uma possível solução definitiva pra parte gráfica.
Queria saber se na prática é possível, ou se estarei falando besteira.

Pois bem, vamos em partes:

No VB6 temos lá nos textbox os eventos gotfocus() quando o textbox recebe o foco, lostfocus() quando o textbox perde o foco, keypress() quando é digitada uma tecla.
Temos também o activecontrol() que seria parecido com readvar(), que equivale ao controle atual.
Qualquer formatação de digitação pode ser feita em keypress(), que seria o inkey() do textbox dentro do VB.
Se isso pode ser feito no VB, no Harbour também.

Agora voltemos ao Harbour, ou a getsys do clipper 5.3:
Ela tem tudo pra trabalhar com gets, botões, tbrowse, e.... verificar teclado e mouse através de inkey().
Ou seja, tudo pra uma interface gráfica.

Olhando o demo da gtwvw ela tem o nAfterInkey(), que processa tudo que é feito em modo gráfico.
Pois bem: se a getsys já atende tudo de navegação, porque não usar a getsys em modo gráfico.
Não será esse o erro das LIBs gráficas? tem uma getsys poderosa e eficiente no Harbour, e inventam de fazer tudo diferente?
Pelo que sei, a minigui ainda não faz o que a getsys faz, ou seja, bastaria usar a getsys pra resolver bugs de anos...

Isso é possível na prática?

[Pablo César]

Não sei se entendi diereito, o que você quer é utilizar o GetSys.prg em modo console para programação gráfica. Eu não sei quanto GTWVW ou até mesmo em HwGui, mas pelo pouco que entendo de programação gráfica é totalmente diferente todo o controle e validação dos eventos. Programar em modo gráfico tem outro conceito outra característica, não creio que valha a pena fazer adaptações ora porque o comportamento de cada componente (TextBox, Spinner, Button, etc.) se dá de forma diferenciada. Creio que programar em modo gráfico é programar de forma totalmente diferente com a que vínhamos fazendo em modo console. É outro mundo.

[JoséQuintas]

Aí que está.... não é.
Se olhar a getsys do clipper 5.3, ela tem:
get - seria o textbox
button - seria o commandbutton
tbrowse - seria o combobox e similares
memoedit - seria o textbox multiline

já postei aqui um exemplo de tabs usando getsys.

Acho que o problema está justamente em achar que tem que ser diferente.

[Pablo César]

Olha eu juro que eu tentei me segurar para rebater no que você falou. Mas desculpe, não tem nem comparação !

Sem entrar no mérito que a programação GUI tem um aspecto e funcionabilidade diferente com a de console, posso citar ao menos quais são as atuais características de cada elemento que você citou:

TextBox:

Propriedades: BackColor, Border, CaseConvert, Col, DataType, Field, FontBold, FontColor, FontItalic, FontName, FontUnderLine, FontSize, FontStrikeOut, Format, Height, HelpId, InputMask, MaxLength, Name, Password, ReadOnly, RightAlign, Row, TabStop, ToolTip, Value, Visible e Width

Eventos: OnChange, OnEnter, OnGotFocus e OnLostFocus

Button:

Propriedades: Caption, Col, Flat, FontBold, FontItalic, FontName, FontUnderLine, FontSize, FontStrikeOut, Height, HelpId, MultiLine, Name, Row, TabStop, ToolTip, Transparent, Visible e Width

Eventos: Action, OnGotFocus e OnLostFocus

ComboBox:

Propriedades: Col, DisplayEdit, DroppedWidth, FontBold, FontItalic, FontName, FontUnderLine, FontSize, FontStrikeOut, Height, HelpId, Items, ItemSource, Name, Row, Sort, TabStop, ToolTip, Value, ValueSource, Visible e Width

Eventos: OnChange, OnCloseUp, OnDisplayChange, OnDropDown, OnEnter, OnGotFocus e OnLostFocus

EditBox: (Substituindo o MemoEdit)

Propriedades: BackColor, Col, Field, FontBold, FontColor, FontItalic, FontName, FontUnderLine, FontSize, FontStrikeOut, Height, HelpId, HScrollBar, MaxLength, Name, ReadOnly, Row, TabStop, ToolTip, Value, Visible, VScrollBar e Width

Eventos: OnChange, OnEnter, OnGotFocus e OnLostFocus

Browse:

Propriedades: AllowAppend, AllowDelete, AllowEdit, BackColor, Col, DisplayItems, DynamicBackCol, DynamicForeCol, Fields, FontBold, FontColor, FontItalic, FontName, FontUnderLine, FontSize, FontStrikeOut, Headers, HeaderImages, Height, HelpId, Image, InputItems, Justify, Lines, Lock, Name, ReadOnlyFields, Row, TabStop, ToolTip, Valid, ValidMessages, Value, VScrollBar, Visible, When, Width, Widths e WorkArea

Eventos: OnChange, OnEnter, OnGotFocus e OnLostFocus

Isso também sem contar os outros elementos que não foram mencionados como: CHECKBOX, LIST, CHECKBUTTON, GRID, SLIDER, SPINNER, IMAGE, TREE, DATEPICK, LABEL, TIMER, RADIOGROUP, FRAME, TAB, ANIMATEBOX, HYPERLINK, MONTHCAL, PROGRESSBAR, IPADDRESS...

E outras propriedades como: Cursor, HelpButton, Icon, MaxButton, MinButton, NotifyIcon, NotifyTooltip, Sizable, SysMenu, Title, TitleBar, Topmost, Virtual Size, Virtual Height, Virtual Width e WindowType

Imagine tudo isto que existe no HMG/MINIGUI e ainda adaptá-lo no GetSys... acho que todo um trabalho que nem sei se seria possível e ainda a troco de quê ? Abra sua mente, amigo. Sei que custa, porque todos nós já passamos por isso e alguns ainda irão passar. Mas são técnicas diferentes. Eu um dia cheguei a pensar nisso, mas vi que trabalhar adaptando a uma modalidade: seria como engessar uma IDE um ambiente de trabalho. Desculpe, mas total em desacordo. Claro que sempre é bem vindo novas ideias e até mesmo ideias revolucionárias. Mas esta ? A troco de quê ? Pense !

[JoséQuintas]

Pois é, é disso que estou falando. Vou pegar só o textbox, que é o básico e talvez o principal:

CaseConvert: isso é pra converter pra maiúscula? seria picture "!A"

DataType: Isso é o tipo de conteúdo, a getsys pega pela variável.

Field: Isso indica conteúdo de campo de arquivo, na getsys não faz diferença se é variável ou campo de arquivo.

Format: Formato especial, não seria picture?

InputMask: Máscara de digitação, não seria picture?

MaxLenght: Tamanho máximo, não seria picture ou tamanho da variável?

RightAlign: Alinhar à direita, a getsys faz, ou pode fazer

Readonly: Não deixar mexer... não seria when .f.

TabStop: Ordem de executar, isso até o primeiro Clipper já tinha

Value: Conteúdo, normal

Onchange: Se alterou... é a getsys e o updated()

Password: Formato pra senha, tem na getsys

Name: o Nome a getsys tem

Row,Col: Posição, a getsys tem

Propriedades: BackColor, Border, FontBold, FontColor, FontItalic, FontName, FontUnderLine, FontSize, FontStrikeOut, Height, HelpId, ToolTip, Visible e Width
Eventos: OnChange, OnEnter, OnGotFocus e OnLostFocus

É justamente esta última parte que complica. A maioria tem a ver com o desenho, e não com o conteúdo.

A getsys tem 30 anos, normal faltarem coisas nela. O que não é normal é o controle "evoluído" precisar de tanta coisa pra não fazer o que a getsys faz.
É incrível acharem que precisam de tantas propriedades, só pra fazer o que uma picture deveria fazer, e ainda acharem que isso é certo.

Não sei se os caras lá me entenderam, mas falei justamente sobre isso: a era Harbour Gráfico está se preocupando com quantidade e não qualidade.
Tá na hora de separar o que é útil do inútil, porque senão o Harbour vai virar somente outra linguagem tranqueira, cheia de porcaria inútil que não resolve o problema.

E a primeira coisa que ouço sobre a QT é que tem mais recursos. Será que permite informar uma picture?

[JoséQuintas]

Só complementando:
A maioria dos programadores Clipper ficou na versão 5.2, eu também, e acabamos esquecedo uma grande diferença no 5.3:

- A getsys do 5.3 também controla botões
- A getsys do 5.3 também controla tbrowse
- A getsys do 5.3 também controla memoedit
- A getsys do 5.3 também controla mouse
- O 5.3 também tem opção de modo gráfico, e a getsys tem algo pra isso

Tudo que uma interface gráfica faz, o Clipper 5.3 faz, só deixou de evoluir.
Tudo que existe hoje nos programas atuais são evoluções.
Então, é só evoluir a getsys.

Imagine se todas as LIBs gráficas fossem por esse caminho, utilizando a getsys como parte central....
Seriam todas compatíveis, e o Harbour estaria longe.
Ao invés disso, cada uma fez sua própria getsys, e cada uma tem um ponto onde se destaca.

Vamos a conceitos, não a prática:
um controle tem lá o gotfocus,lostfocus, onclick, keypress, etc. Seria passar isso à getsys.
oGet:Display()
Sendo uma classe, basta criar as classes equivalentes aos controles. E essas classes poderiam modificar fonte, tamanho de fonte, cor de fundo, cor de fonte, etc., não precisa ser dentro da getsys.
É apenas um conceito, teórico.
Vou estudar a gtwvw, porque parece que ela tem alguma coisa disso.

[Imatech]

.
.
.
Imagino o quão complexo seria tratar os eventos do SO ( em windows: windows process messages / forms)... visto que Harbour é suportado em diversas plataformas...
A exemplo: em wvg é usado para manter objetos gráficos ( imagens,, etc... ) em exibição: WvtPaintObjects()

Código: Selecionar todos

/*-*/
/*
 *        This function must have to be defined in your appls
 */
function Wvt_Paint()

   /* Call this function from this funtion */
   WvtPaintObjects()

   return nil

.
.
.
hbQT já tem tudo pronto para uso (vai bem alem do que a grande maioria dos programadores estão habituados)... e pode ainda migrar gradualmente mixando com o código console (crt, wvt, wvg, wvw )...
.
.
.
Sugiro um simples teste, onde se ira criar uma tela para o Munu Principal, Splash Screeen e Tela de acesso para o usuario...
Resultados rápidos e agradavel interface de trabalho...
.
.
.

[JoséQuintas]

No Harbour 3.0 oficial tem hbqt, e no nightly também.
Compilei com a configuração padrão, de mingw, TODOS dão GPF.
Executam, abrem as telas bonitas, clicou numa opção abre, mas em seguida GPF.
Desse jeito, pode até ser o futuro, mas queria algo mais para o presente.

Vou tentar colocar em prática o que estou falando com a gtwvw, parece que ela tem tudo pronto para fazer do jeito que falei. Vai ser o jeito.

[microvolution]

Vai ser o jeito.

fora vencido pelo cansaço.