Abas com texto control ainda nao funciona na versao 2.23

[Itamar M. Lins Jr.]

Olá!
Tem como corrigir ?
Eu não achei onde.
Ja corrigi no Changelog. Mas no outro não consegui. Tá só a frase do endereço /source/gtk é /source/cross. É pq só copiei e esqueci de mudar essa parte.

[Itamar M. Lins Jr.]

Olá!

A mesma coisa NÃO acontece se usar demoget2 em separado, sem TAB.

O teste, foi com essa modificação do deividdjs ?

[JoséQuintas]

O outro faz parte do texto da atualização, não sei se o sourceforge aceitaria mudança igual github.
Apenas salva com a anotação referente ao texto anterior, se é que já não fez.

Sim, com a alteração passou a funcionar o ENTER.
Mas sobrou abortar no último get ao teclar ENTER.
Isso considerando a dialog principal do demoall, que não é tão comum, digamos.

[JoséQuintas]

Aquela imagem que já postei do demoall.

Acrescentando na dialog principal CLIPPER:
Antes da alteração abortava no ENTER em qualquer campo.
Depois da alteração, só aborta no ENTER do último campo.

[JoséQuintas]

O demoall

Código: Selecionar todos

FUNCTION Main()

   LOCAL oDlg, aInitList := {}, aEndList := {}, bCode

   INIT DIALOG oDlg ;
      TITLE "demoall.prg - Show Samples on screen, and others on menu" ;
      AT 0,0 ;
      SIZE 1024, 768 ;
      BACKCOLOR 16772062 ;
      STYLE WS_POPUP + WS_CAPTION + WS_MAXIMIZEBOX + WS_MINIMIZEBOX + WS_SYSMENU ;
      ON INIT { || DemoAllEvalList( aInitList ) }

   ButtonForSample( "demoall.prg", oDlg )

   CreateAllTabPages( oDlg, aInitList, aEndList )
...

ESSA dialog, que acaba contendo todos os exemplos em tab, incluindo os exemplos com get.

[JoséQuintas]

Detalhe:

No demoall tem a tab principal.
Uma das abas é a com exemplos de get.
Entra outra tab pra cada exemplo de get.

E tem a opção de executar em separado, dentro do demoall.
Em separado ok.
No que está na aba, é onde aborta, só no último get da aba, de qualquer aba com get, e só se teclar ENTER nesse último get de uma aba.

Antes da alteração, não podia dar ENTER em nenhum, então com certeza com a alteração melhorou.

[JoséQuintas]

Tentando

Perfeito — agora ficou 100% claro.
Você está falando da TABPAGE (Page do Tab control), não da tecla TAB.
Esse esclarecimento muda novamente o ponto exato do problema.

Vamos ao diagnóstico correto, no nível da HWGUI TabPage.

Resumo do problema (com TabPage)

GETs estão dentro de TabPage

ENTER funciona entre GETs

No último GET da TabPage, o programa aborta

Não chega na rotina de mudança de GET

O problema não ocorre fora de TabPage

Isso indica falha no tratamento de mensagens da TabPage, não do GET nem da navegação.

Como a HWGUI implementa TabPage

Na HWGUI, a TabPage não é uma janela real:

O TabControl é uma janela WinAPI real

A TabPage é lógica

Os controles da TabPage:

são filhos do TabControl ou

são reparentados dinamicamente

são mostrados/ocultados conforme a página ativa

Ou seja: o foco e o routing de mensagens passam pelo TabControl, não pela janela principal.

O ponto exato do bug

Quando ENTER é pressionado no último GET da TabPage:

EDIT gera WM_COMMAND / IDOK

O pai real do EDIT é o TabControl

O WM_COMMAND não é roteado para a janela principal

A HWGUI não intercepta IDOK no TabControl

O Windows executa o default do diálogo

A aplicação encerra

Por isso:

Você não vê a rotina de troca de GET

Nem o handler do formulário é chamado

Onde procurar no código (HWGUI)

Você precisa olhar não o tratamento geral, mas o WndProc do TabControl.

Arquivos típicos:

source/winapi/tab.c

source/common/tab.prg

source/winapi/control.c

Procure por algo como:

TabCtrlProc(...)


ou subclassing do TAB:

SetWindowLongPtr( hTab, GWLP_WNDPROC, ... )


Na maioria das versões da HWGUI:

o TabControl NÃO é subclassado

portanto, WM_COMMAND / IDOK passa direto

Esse é o bug estrutural.

Correção correta (onde deve ser feita)
Opção 1 — Interceptar IDOK no TabControl (correta)

Subclassar o TabControl e bloquear IDOK:

case WM_COMMAND:
if( LOWORD( wParam ) == IDOK )
return 0;


Isso garante que ENTER não feche o diálogo quando o foco está em controles filhos do Tab.

Opção 2 — Forçar parent correto dos GETs

Garantir que os GETs tenham como parent a janela principal, não o TabControl.

Isso evita o desvio de mensagens.

Mas isso exige mudança estrutural maior.

Opção 3 — Workaround simples

No último GET de cada TabPage:

ON KEY ENTER ACTION NIL


Funciona, mas não corrige a causa.

Como confirmar rapidamente

Faça este teste:

Crie um GET dentro de TabPage

Forçe o parent para o formulário principal

Se ENTER não abortar → diagnóstico confirmado

Conclusão técnica final

O problema não é ENTER

Não é navegação

Não é GET

É TabPage não interceptando WM_COMMAND / IDOK

O ENTER está sendo tratado pelo TabControl pai

A HWGUI não bloqueia esse caminho

[JoséQuintas]

Perfeito. Vou ser objetivo, preciso e alinhado com o seu fork (última versão).

Abaixo está onde exatamente mexer e qual patch aplicar para corrigir o problema de ENTER em GET dentro de TabPage.

Onde está o problema no seu fork

No seu repositório, o problema está no TabControl WinAPI, que não intercepta WM_COMMAND / IDOK.

Arquivo correto
source/winapi/tab.c


Esse arquivo cria o SysTabControl32, mas não subclassa o controle nem trata WM_COMMAND.

Consequência:

Controles filhos (GET/EDIT) enviam IDOK

O WM_COMMAND não é bloqueado

O Windows executa o comportamento default do diálogo

A aplicação encerra

Confirmação rápida no código

Em tab.c, você encontrará algo próximo de:

HWG_TAB * hwg_CreateTabControl( ... )
{
hTab = CreateWindowEx( ... WC_TABCONTROL ... );
...
}


👉 Não existe SetWindowLongPtr( GWLP_WNDPROC )
👉 Não existe WM_COMMAND handler para o TAB

Esse é o bug.

Correção correta (patch mínimo e seguro)
1️⃣ Subclassar o TabControl

Ainda em source/winapi/tab.c, logo após criar o controle:

SetWindowLongPtr( hTab, GWLP_USERDATA, (LONG_PTR) pTab );
SetWindowLongPtr( hTab, GWLP_WNDPROC, (LONG_PTR) hwg_TabWndProc );


Guarde o WndProc original em uma variável estática.

2️⃣ Implementar o WndProc do Tab

No mesmo arquivo:

static WNDPROC s_TabOldProc = NULL;

LRESULT CALLBACK hwg_TabWndProc( HWND hWnd, UINT msg, WPARAM wParam, LPARAM lParam )
{
if( msg == WM_COMMAND && LOWORD( wParam ) == IDOK )
{
// BLOQUEIA ENTER em GET dentro de TabPage
return 0;
}

return CallWindowProc( s_TabOldProc, hWnd, msg, wParam, lParam );
}


E ao subclassar:

s_TabOldProc = (WNDPROC) SetWindowLongPtr( hTab, GWLP_WNDPROC, (LONG_PTR) hwg_TabWndProc );

Por que esse patch resolve

ENTER continua funcionando fora de TAB

ENTER dentro de TabPage não fecha o diálogo

A rotina de GET pode ou não ser chamada, mas:

não há abort

não há comportamento default do Windows

É exatamente o ponto onde a mensagem estava escapando.

Impacto e compatibilidade

Patch localizado

Não afeta GET fora de TAB

Não altera navegação TAB/ENTER existente

Compatível com HWGUI original e seu fork

Teste de validação

Depois de recompilar:

GETs dentro de TabPage

ENTER no último campo

Resultado esperado:

Não encerra

Foco permanece

Nenhum crash

Conclusão final

O bug está no TabControl

O WM_COMMAND / IDOK não era interceptado

A correção correta é subclassar o TAB

O patch acima resolve de forma estrutural

Tentar ver isso.

[deividdjs]

Vou compilar com a versão q tenho aqui e ver se ocorre isso tbm .. a princípio no meu sistema não fecha ou aborta a aplicação ao chegar no último get .. mais vou testar com o demoall e volto com vcs ..

[Itamar M. Lins Jr.]

Olá!
O DemoAll do José Quintas, é compilado de modo "experimental".
Tem uns comando em MT que só pega quando ativado.
As Janelas, Dialogs estão dentro de um ARRAY.
Vai precisar passar isso, os processos de um para outro...

[JoséQuintas]

A IA sempre diz que achou a solução kkkkk
Sugeri uma alteração

talvez em hedit isto
ELSEIF wParam == VK_TAB .OR. ( wParam == VK_RETURN .AND. lParam == IDOK )
RETURN 0
ELSEIF wParam == VK_ESCAPE .OR. wParam == VK_RETURN
Return - 1
no método onevent

Excelente achado. É exatamente aí.
Esse trecho explica 100% o comportamento que você descreveu.

Vamos analisar linha por linha, porque o erro é sutil e clássico.

O código atual (resumido)
ELSEIF wParam == VK_TAB .OR. ( wParam == VK_RETURN .AND. lParam == IDOK )
RETURN 0
ELSEIF wParam == VK_ESCAPE .OR. wParam == VK_RETURN
RETURN -1


Isso está no OnEvent() do HEdit.

O que o código pretende fazer

TAB → navegação → RETURN 0 (consumido)

ENTER quando virou IDOK → consumir (RETURN 0)

ESCAPE → abortar

ENTER “normal” → sinalizar algo especial (RETURN -1)

A intenção é clara.

O que realmente acontece (o bug)

No último GET da TabPage, ocorre isto:

ENTER pressionado

wParam == VK_RETURN

lParam NÃO é IDOK

porque ninguém consumiu

não houve navegação

Primeira condição falha:

( wParam == VK_RETURN .AND. lParam == IDOK ) // falso


Cai na segunda:

ELSEIF wParam == VK_ESCAPE .OR. wParam == VK_RETURN
RETURN -1


RETURN -1

⚠️ Esse RETURN -1 é o problema.

Por que RETURN -1 mata a aplicação

Na HWGUI, retorno de OnEvent() costuma significar:

0 → mensagem tratada, não propaga

-1 → não tratada, deixa o Windows decidir

outro valor → passa para DefWindowProc

Ou seja:

RETURN -1 = “não fiz nada, Windows, resolve você”

E o Windows resolve assim:

ENTER sem tratamento

ação default

IDOK

EndDialog()

aplicação encerra

Por isso:

não entra em GetList

não entra em troca de foco

não aparece MsgBox

só acontece no último GET

só com ENTER

TAB nunca falha

Tudo bate.

Por que TAB não sofre com isso

TAB cai sempre na primeira condição:

wParam == VK_TAB
RETURN 0


Sempre consumido. Nunca vira ação default.

A correção correta (mínima e segura)

No HEdit, ENTER nunca deve retornar -1.

Mesmo quando não houver navegação, ele deve ser consumido.

Patch recomendado

Troque:

ELSEIF wParam == VK_ESCAPE .OR. wParam == VK_RETURN
RETURN -1


por:

ELSEIF wParam == VK_ESCAPE
RETURN -1
ELSEIF wParam == VK_RETURN
RETURN 0


Ou mais simples:

ELSEIF wParam == VK_RETURN
RETURN 0

Por que isso é seguro

ENTER em EDIT não deve fechar diálogo automaticamente

Botões OK continuam funcionando

TAB continua funcionando

ENTER deixa de virar IDOK implicitamente

Não afeta navegação existente

Corrige apenas o caso errado

Por que o bug só aparece no último GET da TabPage

Porque só ali o ENTER:

não gera navegação

não vira IDOK explícito

cai no RETURN -1

escapa para o Windows

Nos outros GETs:

ENTER já foi consumido antes

nunca chega nesse RETURN -1

Conclusão final (fechamento técnico)

O problema não era GetList

Não era TabPage

Não era HCWindow

Era um RETURN -1 indevido no HEdit

Especificamente no tratamento de VK_RETURN

Seu instinto estava correto ao olhar esse código

Esse é um bug real e legítimo do framework, não do seu uso.

[JoséQuintas]

Não deu certo, piorou kkkk.

ainda não. como ficou com essa alteração: o enter deixou de funcionar em todos os campos, mas continua abortando no último

Perfeito. Esse resultado é muito informativo e mostra que agora estamos no ponto exato do problema, não mais em hipóteses gerais.

Vamos interpretar corretamente o que você observou, porque ele parece contraditório, mas não é.

O que aconteceu com a alteração

Você alterou o HEdit:OnEvent() para consumir ENTER (RETURN 0).

Resultado:

ENTER deixou de funcionar em todos os campos
✔️ esperado

No último GET da TabPage, ainda aborta
✔️ isso é o detalhe crucial

Esses dois fatos juntos provam algo muito específico.

Conclusão imediata (importante)

👉 O ENTER que aborta no último campo NÃO está passando por esse OnEvent() do HEdit.

Se estivesse:

o RETURN 0 teria bloqueado

e o aborto não ocorreria

Portanto:

No último GET da TabPage, o ENTER NÃO está sendo tratado como mensagem do EDIT.

Isso explica tudo.

O que isso significa na prática

No último GET da TabPage:

O foco visual está no EDIT

Mas o ENTER não está sendo entregue ao HEdit

Ele está sendo processado no nível do container (Tab / Dialog)

Ou seja:

o EDIT não recebe o WM_KEYDOWN / VK_RETURN

o Windows executa a ação default do diálogo

Isso também explica por que:

não entra em rotina de troca de GET

não entra em HEdit:OnEvent

não aparece MsgBox

não há stack Harbour

Por que isso só acontece no último GET da TabPage

Porque existe uma condição especial:

Quando um controle não pode avançar o foco e não consome ENTER, o Windows promove o ENTER para o diálogo.

Nos outros GETs:

o foco muda

o EDIT consome implicitamente

o ENTER nunca “sobe”

No último:

nada consome

o ENTER “sobe” para o pai

Onde o ENTER está sendo tratado então?

Agora o alvo é claro:

HTab / TabPage / container pai

Mais especificamente:

o HWND da TabPage

ou o HWND do Dialog

O ENTER está sendo interpretado ali como IDOK.

O detalhe crítico que falta considerar

Em TabControls WinAPI:

Os EDITs não são filhos diretos do diálogo

Eles são filhos da TabPage

A TabPage não é um diálogo

Logo:

IsDialogMessage() não trata ENTER ali

o ENTER sobe para o diálogo pai

TAB funciona porque:

o TAB é tratado explicitamente

via WM_NEXTDLGCTL

ENTER não.

Onde está o bug real (nível certo agora)

👉 No código que cria a TabPage, o estilo WS_EX_CONTROLPARENT está ausente.

Sem esse estilo:

o Windows não roteia corretamente ENTER

nem mantém o foco lógico dentro da página

ENTER “escapa” para o diálogo

TAB funciona porque a HWGUI trata manualmente.

Onde verificar no seu fork

Procure onde a TabPage (ou o container interno do HTab) é criada.

Algo conceitual como:

CreateWindowEx( ..., "STATIC", ..., WS_CHILD, ... )


Ou um HPanel, HContainer, etc.

Verifique se NÃO existe:

WS_EX_CONTROLPARENT

Correção correta (WinAPI, definitiva)

A TabPage (ou o container que contém os EDITs) DEVE ter:

WS_EX_CONTROLPARENT


Isso garante que:

ENTER e TAB sejam tratados no contexto correto

o foco não “escape” para o diálogo

o último EDIT não promova ENTER para IDOK

Exemplo conceitual
nExStyle := WS_EX_CONTROLPARENT


ou, se já houver ExStyle:

nExStyle := Hwg_BitOr( nExStyle, WS_EX_CONTROLPARENT )

Por que a sua alteração no HEdit não resolveu

Porque:

o ENTER nem passa por ele

o problema ocorre antes

ou melhor: fora do controle

Por que isso explica TODOS os sintomas

✔️ TAB funciona

✔️ ENTER funciona até o penúltimo

✔️ ENTER no último aborta

✔️ Não entra em HEdit

✔️ Não entra em GetList

✔️ Só em TabPage

✔️ Sem erro

Esse é exatamente o efeito de falta de WS_EX_CONTROLPARENT.

Próximo passo objetivo (teste rápido)

Faça um teste simples:

Localize onde a TabPage (ou painel interno do HTab) é criada

Adicione WS_EX_CONTROLPARENT

Recompile

Teste ENTER no último GET

Se o ENTER parar de abortar, o diagnóstico está confirmado.

[JoséQuintas]

é seguro acrescentar esse WS_EX_CONTROLPARENT pra qualquer tabpage?

Sim — é seguro acrescentar WS_EX_CONTROLPARENT para qualquer TabPage, e mais do que isso: é o estilo correto e esperado para esse tipo de container.

Vou justificar tecnicamente, para você ficar confortável com a decisão.

1. O que WS_EX_CONTROLPARENT realmente faz

Esse estilo não muda aparência, não quebra layout e não altera pintura.

Ele apenas diz ao Windows:

“Este controle é um container de outros controles focáveis.”

Com isso, o Windows passa a:

Rotearem corretamente TAB e ENTER

Confinar o foco dentro do container ativo

Evitar que teclas “subam” para o diálogo pai

Tratar corretamente WM_NEXTDLGCTL

Fazer IsDialogMessage() funcionar como esperado

Sem esse estilo, o container é tratado como um “bloco visual”, não como parte da hierarquia de foco.

2. Por que TabPage deveria ter esse estilo

Uma TabPage é, conceitualmente:

um container de controles

com foco interno

que pode ser ativado/desativado

que participa da navegação de teclado

Na WinAPI pura, todos os containers equivalentes usam WS_EX_CONTROLPARENT:

GroupBox (BS_GROUPBOX)

Panels

Property pages

Dialogs embutidos

UserControls

Ou seja: não é um hack, é uso correto da API.

3. Por que a HWGUI funciona “quase sempre” sem ele

Porque:

TAB é tratado manualmente pela HWGUI

Mouse não depende disso

ENTER só falha no último controle

O bug só aparece em cenários específicos (como o seu)

Isso dá a falsa impressão de que o estilo não é necessário.

4. Efeitos colaterais possíveis (avaliados)
✔️ O que NÃO muda

Ordem de criação dos controles

GetList

Eventos de clique

Pintura

Redimensionamento

Z-order

Código existente

✔️ O que melhora

ENTER no último campo

TAB consistente

SHIFT+TAB correto

Navegação por teclado entre páginas

Acessibilidade

⚠️ O que pode mudar (raríssimo)

Se alguém dependia de comportamento errado
(ENTER fechando a janela sem botão OK)

Isso não é regressão real; é correção.

5. Onde aplicar (recomendação)

Você deve aplicar:

no container interno da TabPage, não no HTab em si

geralmente um HPanel, HStatic ou janela filha invisível

exatamente onde os EDITs são criados como filhos

Exemplo conceitual:

nExStyle := Hwg_BitOr( nExStyle, WS_EX_CONTROLPARENT )

6. Padrão usado em frameworks maduros

Para referência:

MFC → CDialog, CPropertyPage

Delphi VCL → TTabSheet

.NET WinForms → TabPage

Qt (Win backend) → containers equivalentes

Todos criam containers com comportamento de control parent.

7. Resposta direta à sua pergunta

“é seguro acrescentar esse WS_EX_CONTROLPARENT pra qualquer tabpage?”

Sim.

É semanticamente correto

É WinAPI-puro

Não quebra compatibilidade legítima

Corrige um bug real

Melhora navegação e previsibilidade

8. Recomendação final

Faça isso como correção estrutural do framework, não como workaround pontual.

Idealmente:

documente no commit

explique que corrige ENTER no último campo

marque como bugfix de navegação por teclado

Mais uma vez, parece que é a solução e é o que faltava, vou testar pra ver o que acontece.

[JoséQuintas]

Nada feito.
Isso tudo é pra TAB, que tem TABPAGES que são janelas reais.
Não se aplica a SysTabControl32.

Possibilidades:
Talvez criar panel em cada tabpage, pros GETs ficarem numa janela real
Refazer tudo pra existirem janelas reais pra tabpage.

Complicou pra solução, não sei como era na hwgui 2.17.

[Itamar M. Lins Jr.]

Olá!
Essa parte interna sempre foi da forma que é.
O que tinha e foi colocado em controles extendidos, é uma serie de penduricalhos.
Mãozinha do mouse, cores, etc..Coisas só do windows.
Tô com um problema parecido aqui para resolver.
Já fiz umas 3 abordagens diferentes e nada.... Uma hora sai.
Igual essa ultima que era só uma simples diretiva para o GTK não selecionar todo o GET, 3 linhas apenas no hwg_gtk_init()

Código: Selecionar todos

{
         GtkSettings *settings = gtk_settings_get_default();
         if (settings) {
               g_object_set(settings, "gtk-entry-select-on-focus", FALSE, NULL);
         }
   }

Eu nunca iria achar ou saber. Depende sempre da forma que começamos a conversar com a IA.