Travando em DATAS

[Itamar M. Lins Jr.]

Ola!
Se teclar <enter> não sai. Mas volta p/ edição quando teclar qualquer outra tecla.
No caso vc terá que criar sua função de validação da data, reinventar a roda...

Saudações,
Itamar M. Lins Jr.

[JoséQuintas]

Misturar LIB gráfica, ou mesmo várias janelas, não é fácil.
De repente o alerta de data inválida, ou o Inkey(0) seguinte, estão indo pra janela errada.
Já disse que está misturando MINIGUI com GTWVT, então vai ter que revisar a mistura.

Aliás... se teve que montar a janela modal pra não fechar automático, já percebeu que nem espera por digitação, e já tinha algo errado antes.

Como regra de sempre:
Crie um exemplo simples, reduzido, com esse problema, pra ficar mais fácil de alguém analisar.
Não adianta dizer que o problema é no GET, porque não é, é no conjunto.

Aproveitando.... estranhei a digitação de data com picture.
Aproveitando de novo... estranhei isto HB_GTINFO( HB_GTI_ISFULLSCREEN, .F. ) // Deixar a tela cheia - estilo DOS

[FFreire]

Vamos lá...

Itamar... não sai... nem dando enter, nem nada, simplesmente trava, aparece no canto direito superior a mensagem de "invalid date" e fica lá piscando... nem para frente, nem para trás...vou dar uma olhada no errorsys, se passa por lá... mas não sei mais o que fazer...

José... o estranho é que fiz um exemplo aqui... bem simples... como o Itamar disse... e mesmo assim trava... dai não tem minigui, nem GTWVT, nada... seria compilação harbour no console... Sobre a data com picture, sempre usei e nunca tive problemas... eu tenho uma tabela com todas as minhas mascaras, então dai uso uma função que retorna a mascara que quero usar... dessa forma, se muda a mascara de algum campo, é só acertar no código da tabela... uso assim... @ 10,10 GET xnome PICT RetMasc('001'), dai na função é feito uma busca desse código que foi passado e me retorna a mascara que quero usar... mas no caso da data, ja tirei a mascara, ja fiz de tudo que pensei até aqui, data inválida, trava o sistema... como disse fiz um teste com o scoreboard desligado e aparece a msg de data inválida, mas fica piscando lá e não sai... só fechando via gerenciador de tarefas... sobre o HB_GTI_ISFULLSCREEN, veja que esta com .F., para não deixar que o usuário deixe a tela cheia, ja usava em tamanho janela as telas do meu sistema, então não permito a tela cheia dai...

Mas enfim... quem puder ajudar...agradeço !

F.Freire

[alxsts]

Olá!

Coloque este GET dentro de um bloco BEGIN SEQUENCE... RECOVER... END SEQUENCE.

Código: Selecionar todos

PROCEDURE SuaProc

   LOCAL bError := ErrorBlock( {|e| Break(e) } ), oErr, GetList := {}

   BEGIN SEQUENCE

      @x, y SAY 'Abc: ' GET .....

      READ

      HB_Alert( { "   Tudo Ok   " } )
      
   RECOVER USING oErr
      HB_Alert( { "Ocorreu o erro : " + oErr:subSystem + "/" + Ltrim(Str(oErr:subCode)), "DOS Error " + LTrim(Str(oErr:osCode)), "Descricao: " + oErr:description, "Operacao: " + oErr:Operation, "Arquivo: " + oErr:fileName },{ 'Ok' },"W+/B", 15 )
   END SEQUENCE

   ErrorBlock( bError )

RETURN

Verifique se cai no bloco do RECOVER

[FFreire]

Bom dia...

Vejam... fiz o que o alxsts recomendou e trava mesmo assim, não entra no RECOVER, fica travado no GET... pois não da erro e fica travado, como informei acima, acredito que deva ser um bug no comando GET, se for isso, gostaria que o pessoal que tem contato com o team da minigui extend, informasse o erro, para poder ser corrigido...lembrando também que na nova versão 2.4.9, da dando erro quando linka... falta uma função lá...

Acredito ser um problema no harbour que vem com a minigui extend... por que penso isso... porque compilei/linkei no hmg3.4.0 e não dá o travamento... agora ferrou... porque tem muita coisa que uso que só tem no minigui extend...

Será que posso, simplesmente, baixar o fonte do harbour e criar as libs com o BCC ? dai colocar para compilar/linkar, esquecendo o harbour que vem com a minigui extend?

F.Freire

[JoséQuintas]

Ainda acho que tem a ver com a mistura.
Talvez tenha que usar multithread para a mistura.

Teste um exemplo simples.
É apenas pra teste.

Código: Selecionar todos

hb_ThreadStart( || SeuModulo() )

E no módulo, também vai complicar um pouco porque há duas situações: quando já está carregado e quando não está carregado. ( hb_GtLoad(), hb_gtReload() )
Não sei como fica isso na mistura.

Código: Selecionar todos

FUNCTION SeuModulo()
   LOCAL dData := Date()
   hb_gtReload( "GTWVT" )
   CLS
   @ 12, 20 SAY "Data:" GET dData
   READ
   RETURN NIL

Só pra lembrar:
em multithread, o módulo executado não enxerga nada da outra thread, nem mesmo algumas configurações básicas, é como se fosse um EXE separado.
Pode acontecer do programa ficar zumbi e ter que fechar pelo gerenciador de tarefas.
Por enquanto é apenas teste.

Sim... Também precisa ver se a minigui e a GTWVT estão preparadas pra trabalhar em conjunto.
É porque o núcleo principal das LIBs pode precisar estar carregado simultâneo.
Talvez multithread simplifique isso (e complique outras coisas).

Última coisa: as GTs como GTWVG, GTWVT, etc. trabalham em console como "monojanela". Mais de uma janela precisam tratamentos especiais. Junto à minigui é onde poderia causar problema, porque estariam "roubando" todo funcionamento da minigui ou vice-versa, porque cada uma quer o controle pra si. É mais ou menos isso, não técnicamente desse jeito.

[asimoes]

Freire,

Você pode baixar o harbour oficial (core) compilar com o bcc 5.82 (funciona) as versões acima (6.3) apresentam comportamentos estranhos com a minigui.


Compilar o harbour

Criar uma pasta MiniguiCore (com todos os arquivos da minigui)

Copiar da pasta compilada do harbour: harbour.exe e hbmk2.exe (substituir)
Copiar da pasta compilada do harbour a pasta include (substituir)
Copiar todas as libs da pasta compilada do harbour para pasta lib (substituir)

Na pasta SOURCE criar esta bat para compilar:

MakeAllMiniguiLibs_BCC58.bat

Código: Selecionar todos

@echo off

SET MG_BCC=\Borland\BCC582
SET MG_ROOT=\MiniGuiCore

rem Makes all MiniGui libraries from folders under SOURCE folder.

@echo.
@echo MiniGui.lib
@echo.
call MakeLib.Bat %1 %2 %3 %4 %5 %6 %7 %8 %9

@echo.
@echo dbginit.obj
@echo.
call MakeObj.Bat %1 %2 %3 %4 %5 %6 %7 %8 %9

@echo.
@echo PropGrid.lib
@echo.
cd PropGrid
call MakeLib.bat %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..

@echo.
@echo PropSheet.lib
@echo.
cd PropSheet
call MakeLib.bat %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..

@echo.
@echo TsBrowse.lib
@echo.
cd TsBrowse
call MakeLib.bat %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..

@echo.
@echo HMG_QHTM.lib
@echo.
cd QHTM
call MakeLib.bat %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..

@echo.
@echo WinReport.lib
@echo.
cd WinReport
call MakeLib.Bat %1 %2 %3 %4 %5 %6 %7 %8 %9
cd ..

:END

QQ duvida posta aqui.

[JoséQuintas]

Só complementando:

Não uso minigui, só GTWVG.
Por isso não sei das necessidades especiais da minigui pra combinar as duas.
Mas na GTWVG normal, usando os exemplos, o programa fica trocando teclado/mouse entre as janelas, e até mesmo um simples KEYBOARD precisa ser redirecionado pra janela correta.

Por isso preferi multithread, e usar meus módulos do jeito que sempre usei, sem precisar alterar nada neles.
Foi esse tipo de uso que "inventei", como já comentei há algum tempo atrás, e depois entrou para os exemplos do Harbour.
Não era o jeito normal, aparentemente não tinham pensado nesse tipo de uso, mas ajuda muiiito.

Se tiver outro jeito, melhor.
Usar multithread requer mudanças, principalmente no que se refere a variáveis, já que vão ficar invisíveis.
E também na inicialização de cada thread, já que pode precisar configurar DELETE ON, DATE BRITISH, etc. em cada thread.
No meu caso, basicamente criei um módulo intermediário pra chamar os outros módulos que faz todo serviço necessário.
E variáveis públicas se transformaram em funções.

Já os módulos... não precisaram de nada especial, a não ser trocar as variáveis públicas pelas funções equivalentes.
Por exemplo, o nome de usuário que era a variável p_UserName, agora é a função AppUserName()

Mas dê uma pesquisa nas opções disponíveis.
Como deu pra perceber, pode resolver tudo com um módulo intermediário, sem precisar mexer em cada módulo.
Só precisa descobrir qual se aplica ao seu caso.

[FFreire]

Putz... que loucura... isso tudo por uma validação da data... sabe o que mais me preocupa, é que o resto (aparentemente), esta ok... sem problema algum... rodando legal... só essa questão (por enquanto) que esta me tirando o sono...

O que fiz... além de tudo que li por aqui... peguei no fonte do harbour a tgelist.prg e compilei com os fontes do meu sistema, neste prg tem o que acontece com o get/read, aparentemente, esta travado em um laço while e ainda não entendi por que não sai de lá, na situação de data inválida... mas estou estudando, pelo que pude ver até o momento é o bendito do click do mouse que esta atualizando uma váriável lá e dai esse comportamento... mas não sei exatamente quando... uma coisa que gostaria de tentar era desligar no console o mouse, mas ja tentei algumas coisas e não funcionaram... digo desligar o mouse apenas quando estiver no console... ja notei que se estiver em um get e clicar em outro com o mouse, ele valida o get e vai no get que tiver clicado, talvez desligando, acabe esses problemas... alguém poderia dar uma sugestão de como desligar o mouse no console... outra coisa que pensei é em usar outra GT... mas tenho um pouco de receio, pois esta do jeito que preciso atualmente...

José... sobre a multithread, acho que ainda estou meio cru em todo o assunto e tenho medo de perder o controle, dai arranjar mais problemas ainda... mas vou testar para ver como fica sua sugestão... muito obrigado pela atenção...

Sobre compilar isoladamente o harbour para usar com a minigui extended, acho que o problema não é com o harbour, porque acabei fazendo outros testes e não aconteceu dai... acredito que seja realmente a mistura de HARBOUR com minigui extended com console (GTWVT)... e o uso do mouse no console... mas agradeço a colaboração do ASIMOES...

Sei que isso será temporário, pois a idéia é trocar tudo por GUI e não usar mais console... que no momento esta sendo o problema...

Só para constar, ja comentei que estou usando o CTRL+V, para colar informações em um determinado GET e que quando estou com o console funcionando e estou no word por exemplo, para de funcionar o CTRL+V, parece que o console assume o controle e absorve as teclas, clics, etc... é outro problema também, apesar que esse pode ser contornado, com botão contrário do mouse, opção COLAR... mas acho que tenha relação com a questão da validação da BAD DATE.

No momento seria isso, alguma luz para desligar o mouse no console e ver o que acontece...

F.Freire

[FFreire]

Eita... acho que resolvi o problema....

Em tgetlist.prg tem um METHOD Reader( oMenu, aMsg ) CLASS HBGetList -> ou seja, é um METHOD da classe HBGetList, que administra o READ

Código: Selecionar todos

METHOD Reader( oMenu, aMsg ) CLASS HBGetList

   LOCAL oGet := ::oGet
   LOCAL nRow
   LOCAL nCol
#ifdef HB_COMPAT_C53
   LOCAL nOldCursor
   LOCAL nKey
#endif

#ifdef HB_COMPAT_C53
   IF ::nLastExitState == GE_SHORTCUT .OR.;
      ::nLastExitState == GE_MOUSEHIT .OR.;
      ::GetPreValidate( oGet, aMsg )
#else
   IF ::GetPreValidate( oGet, aMsg )
#endif

      ::ShowGetMsg( oGet, aMsg )

      ::nHitCode := 0
      ::nLastExitState := 0
      oGet:setFocus()

      DO WHILE oGet:exitState == GE_NOEXIT .AND. !::lKillRead
* Aqui eu que comentei
*        IF oGet:typeOut
*           oGet:exitState := GE_ENTER
*        ENDIF

// Aqui ja estava comentado no fonte original
//        IF oGet:buffer == NIL 
//           oGet:exitState := GE_ENTER
//        ENDIF

// Não entrava nesse laço abaixo, na segunda vez, porque nunca era GE_NOEXIT e ficava em um laço infinito, causando o travamento
         DO WHILE oGet:exitState == GE_NOEXIT .AND. !::lKillRead
#ifdef HB_COMPAT_C53
            SetCursor( iif( ::nSaveCursor == SC_NONE, SC_NORMAL, ::nSaveCursor ) )
* Eu comentei
*            nKey := Inkey( 0 )
* Eu implementei, descartando os clicks, aceitando apenas letras, números, etc... que no momento é o que interessa...
            nKey := 0
            WHILE .T.
               nKey := Inkey( 0 )
               IF nKey > 0 .AND. nKey <= 255
                  EXIT
               END
            END
* Até aqui
            SetCursor( SC_NONE )
            ::GetApplyKey( nKey, oGet, oMenu, aMsg )
#else
            ::GetApplyKey( Inkey( 0 ), oGet, oMenu, aMsg )
#endif
            nRow := Row()
            nCol := Col()
            ::ShowGetMsg( oGet, aMsg )
            SetPos( nRow, nCol )
         ENDDO

#ifdef HB_COMPAT_C53
         IF !::nLastExitState == GE_SHORTCUT .AND. ;
            !::nLastExitState == GE_MOUSEHIT .AND. ;
            !::GetPostValidate( oGet, aMsg )
#else
         IF !::GetPostValidate( oGet, aMsg )
#endif
            oGet:exitState := GE_NOEXIT
         ENDIF
      ENDDO

#ifdef HB_COMPAT_C53
      nRow := Row()
      nCol := Col()
      nOldCursor := SetCursor()
#endif
      oGet:killFocus()
#ifdef HB_COMPAT_C53
      SetCursor( nOldCursor )
      SetPos( nRow, nCol )
#endif

      ::EraseGetMsg( aMsg )
   ENDIF

   RETURN Self

Observei que toda vez que era algo inválido, acusava que estava inválido, mas não entrava no laço novamente, para pedir novamente a informação, por causa daquilo que comentei... outra coisa, que complicava era a questão que implementei, sai sempre ao click do mouse, agora só sai se digitar algo da tabela ASCII de 1 a 255... que na verdade é a entrada sem mouse... bom até agora funcionou... vamos ver se vai dar mais algum problema... se conseguirem enxergar algo de problema, com o que comentei, por favor, me informe para que eu possa testar... mas acho que ja era algum problema ali, pois na versão original do tgelist.prg tem um teste ja comentado...

F.Freire

[JoséQuintas]

Uso a mesma Getsys que usava no Clipper, limitando o mouse a um único campo.

Além disso, desativo essas mensagens automáticas.

Código: Selecionar todos

SET SCOREBOARD OFF
SET STATUS OFF

Nenhum motivo especial, sempre usei assim também no Clipper.
Apenas uso a mesma Getsys de antes.

[asimoes]

Sei que o assunto já foi resolvido, mas eu tive um problema parecido, resolvi com LOCAL GetList:={}

[JoséQuintas]

tive um problema parecido, resolvi com LOCAL GetList:={}

Só aproveitando pra "cutucar" o povo.
Significa que se passou na compilação -w3 -es2, tá resolvido, porque obrigaria a fazer isso.