Guardando o Get Aivo

por **asimoes** » 13 Nov 2016 11:04

Vejo muitos exemplo usando GetList := {} e ai? assim perde-se todos os valores dos gets

ex.:

cVar1:=Space(10)
cVar2:=Space(10)

@10,0 Get cVar1
@11,0 Get cVar2
Read

Navegando entre os gets quando GetList:={} só podemos acessar o objeto get com GetActive(), mas eu quero ter os valores dos outros gets, então podemos salvar o get para depois usar.

Salvando o Get

cVar1:=Space(10)
cVar2:=Space(10)

@10,0 Get cVar1 When {|| SaveGet( .t.) }
@11,0 Get cVar2 When {|| SaveGet( .t.) }
Read

FUNCTION SaveGet( lVal )
LOCAL oElemento, oGet:=GetActive(), nElemento
THREAD STATIC aGetList := {}

   FOR EACH oElemento IN aGetList
       IF oElemento[2]:Name = "cTeste1" // utilizando um get salvo
          oElemento[2]:VarPut(Space(10))
          oElemento[2]:UpdateBuffer()
          oElemento[2]:Display()
       ENDIF
   NEXT
    
   IF aScan(aGetList, {|a| a[1] == oGet:Name}) = 0
      aAdd( aGetList, {oGet:Name, oGet} ) //salva o get ativo para posterior utilização
   ENDIF
     
RETURN lVal

por **alxsts** » 14 Nov 2016 23:55

Olá!

Não deixa de ser uma contribuição que pode ser útil em algum momento mas, é conveniente lembrar que a linguagem oferece recursos para esta finalidade.

O comando READ pode receber, opcionalmente, a cláusula SAVE e se isto ocorrer, o array getlist é preservado. Vale também lembrar que o comando READ é pré processado em tempo de compilação e, dependendo da presença ou ausência da cláusula SAVE, pode se transformar em uma ou duas instruções.

cVar1:=Space(10)
cVar2:=Space(10)

@10,0 Get cVar1
@11,0 Get cVar2
Read   // ===> Este Read é transformado em ReadModal( GetList ) ; GetList := {} e o array getlist é descartado

//

cVar1:=Space(10)
cVar2:=Space(10)

@10,0 Get cVar1
@11,0 Get cVar2
Read SAVE   // ===> Este Read é transformado em ReadModal( GetList ) e o getlist é preservado

Este comportamento existe desde o bom e velho Clipper.

por **asimoes** » 15 Nov 2016 11:16

Alexandre,

O problema que eu me refiro é usar:

LOCAL GetList := {}

O comando READ SAVE ou simplesmente READ não preserva o GetList, resolve neste caso salvando o objeto GetActive()

Outra coisa, se não usar GetList:={}, não precisar usar READ SAVE, porque a variável GetList é do tipo PUBLIC

Perguntas:

Informamos LOCAL GetList := {} para não trazer "lixo" de um outro get usado em uma outra rotina, é isso galera?

por **asimoes** » 15 Nov 2016 12:12

Fazendo uns testes cheguei a conclusão que o melhor é usar PRIVATE GetList:={} ao invés de LOCAL GetList:={}
Com private getlist := {} o getlist é iniciado e é "visto" pelo objeto get para todas a variáveis

por **rubens** » 15 Nov 2016 18:30

Boa essa questão...
Eu sempre usei
Local Getlist := {}
Para criar uma Getlist Local somente na função atual.
Quando há um return o GetList anterior tá lá na função que chamou sem alteração..

Rubens

por **asimoes** » 15 Nov 2016 18:52

Rubens,

Você pode usar PRIVATE GetList:={}, assim você usa na função onde tem entrada de get e consegue se for necessário navegar nos gets usando o getlist

Tipo:

LOCAL oElemento
PRIVATE GetList:={}
cVar1:=Space(2)
cVar2:=Space(2)

@10,00 GET cVar1 When {|| NavegaGet() } 
@11,00 GET cVar2 When {|| NavegaGet() }
READ

FUNCTION NavegaGet
   FOR EACH oElemento IN GetList
      WITH Object oElemento
         IF :Name = "cVar1"
            Alert( :varget )
         ENDIF
         IF :Name = "cVar2"
            Alert( :varget )
         ENDIF
      END
   NEXT
RETURN .T.

por **JoséQuintas** » 15 Nov 2016 19:10

No meu ponto de vista:

Totalmente errado, e ensinar a fazer errado.
É criar uma teia de aranha com os fontes, que complica cada vez mais.
As rotinas devem ser o mais independente possíveis.
É usar ao máximo variáveis LOCAIS.

por **asimoes** » 15 Nov 2016 19:25

Quintas

Pra você é errado, pra mim atende.

outra coisa, dá um exemplo bacana ao invés de falar que tá errado, valeu!

por **JoséQuintas** » 16 Nov 2016 02:02

Primeiro exemplo:
inválido, usa variável que não tem no fonte.

Segundo exemplo:
inválido, lembrando que WHEN é executado antes que o GET seja posicionado, portanto não se sabe qual o get que corresponde à posição atual dentro do WHEN.
Em todo caso:

LOCAL GetList := {}, cVar1 :=Space(2), cVar2:=Space(2)

@10,00 GET cVar1 When NavegaGet()
@11,00 GET cVar2 When NavegaGet()
READ

FUNCTION NavegaGet()

IF Lower( ReadVar() ) $ "cvar1,cvar2"
      Alert( ReadVar() )
ENDIF
RETURN .T.

Como percebeu, seus dois exemplos foram inválidos.
Precisaria de algum exemplo válido pra mostrar alguma coisa.

Em todo caso, um exemplo antigo, usando classe por causa das 45 variáveis envolvidas:

http://www.pctoledo.com.br/forum/viewtopic.php?f=43&t=16835

Note que mencionei getsys alterada.

A Getsys original falha na atualização da TELA, pode mostrar conteúdo errado em certas situações.
Nem dá pra dizer que é bug do Harbour, e nem vai ter alteração, já que é exatamente igual no Clipper.

Muito melhor corrigir isso na getsys, e evitar gambiarras em fontes.
A mudança que fiz está com "by JPA", uma variável e dois FOR/NEXT, na função ReadModal()

   DO WHILE ! nPos == 0
      aVarGet := Array( Len( GetList ) )
      FOR EACH oElement IN GetList                                                  // by JPA to otimize screen update
         aVarGet[ oElement:__EnumIndex ] := oElement:VarGet()
      NEXT
      PostActiveGet( oGet := GetList[ nPos ] )
      IF ( VALTYPE( oGet:reader ) == "B" )
         EVAL( oGet:reader, oGet )    // Use custom reader block
      ELSE
         GetReader( oGet, lIsMouse )            // Use standard reader
      ENDIF
      FOR EACH oElement IN GetList                                                  // by JPA to otimize screen update
         IF aVarGet[ oElement:__EnumIndex ] != oElement:VarGet()
            oElement:Display()
         ENDIF
      NEXT
      nPos := Settle( GetList, nPos )
   ENDDO

Uma vez com a getsys corrigida, basta que o conteúdo da variável seja atualizado.
Se o objetivo for apenas atualizar tela, não precisa nada mais além disto.
Pegue o exemplo do post mencionado e faça os testes com e sem alteração na getsys.
Com a getsys alterada, vai ver os valores se alterando durante a digitação.
Com a getsys original, vai ver os valores se alterarem somente quando o GET passar pelos valores, isso se passar pelos valores.
Nos dois casos, os valores vão estar corretos, a diferença vai ser somente em tela.

por **asimoes** » 16 Nov 2016 06:47

Quintas,

Os seus exemplos são bons, mas não resolvem a questão.

Eu conheço readvar() desde quando eu tinha cabelo. Com readvar() eu não tenho como trocar o valor de um get sem a interação do usuário, como por exemplo usar o método undo(), o getlist tem muitas propriedas e métodos que eu posso manipular, com um simples readvar() não rola. Outra coisa sei que o seu getsys é turbinado, mas eu ainda prefiro usar o padrão, porque se eu reinventar a roda me obriga verificar o getsys padrão toda vez que a linguagem atualizar e nem sempre o que é atualizado no harbour aparece no changelog

por **rubens** » 16 Nov 2016 07:26

Bom dia...

Asimoes no caso específico da Getlist ser Publica o Local, me atendeu simplesmente por causa do Caos no meu programa... Já brigo com ele ha uns 20 anos.. Somente de uns 03 anos para cá é que consegui me dedicar mais a ele.
Então existe cada coisa "cabeluda" que eu mesmo não acredito. Daí num dá de refazer. Eu sempre que tenho que fazer alterações e uma rotina tento ao máximo refazer ela, existe muitas situações que só uma reindentação ajuda muito. Daí se a Getlist já vem da função anterior "carregado", tenho que admitir que eu nem sempre sei exatamente o que tem nela. Foram muitas e muitas horas em certas situações para saber que o get já existia e tava interferindo nos gets locais/atuais.. Daí a forma de tentar ter um certo controle foi criar a lista de gets localmente.
Eu tô em processo de migração para a minigui extends (inclusive parece que foi um tiro não muito certeiro porque parece que os usuários da hmg oficial são um número maios, mas ainda temos o suporte direto do Grigory, mas isso é outro caso) Então não posso perder muito tempo com o sistema texto antigo, tá funcionando deixa quieto, num tá corrige e deixa quieto também...
Só que o aprendizado é eterno né...
Tava vendo um livro antigo do Ramalho de 1992, falando exatamente sobre as coisas que usamos hoje e que para mim naquela época era bicho de sete cabeças...
De qualquer forma existe questões que a gente levanta aqui, que você não acredita que perdi tanto tempo e o negócio já existe a pelo menos 25 anos.
Um exemplo é o que você deu em outro post sobre atualizar os gets e o Quintas respondendo lá simplificou que não precisava fazer rotina a rotina e sim alterando o getsys, teria me polpado muitas horas de trabalho..kkk...
Para finalizar a questão de gets na hmg/hmgs é completamente diferente de trabalhar né, na getsys você tem acesso aos objetos mas não visualmente, daí tem que ter um controle muito grande dos elementos da getlist. Na Hmg tá ali no form.

Rubens

por **JoséQuintas** » 16 Nov 2016 07:48

O Harbour SEMPRE vai ser compatível com Clipper.
Minha getsys é a mesma desde os tempos do Clipper.

Meu getsys não é turbinado, ao contrário, é reduzido.

Também sempre fui contra mexer na getsys, ou na errorrsys.
Mas em compilação GUI a errorsys não funciona.
E a getsys original trás problemas.

Mexer só o que mencionei, pra atualizar a tela corretamente, não é nada que possa gerar problemas.
Quando houver uma getsys nova, é provável que não precise mais disso.

por **JoséQuintas** » 16 Nov 2016 08:01

Dá pra considerar bug na getsys ou não?

por **JoséQuintas** » 16 Nov 2016 08:07

E com as alterações que mencionei:

: teste2.png (4.27 KiB) Visualizado 2138 vezes

por **JoséQuintas** » 08 Dez 2016 18:44

Como eu disse, uso a mesma dos tempos do Clipper, e funciona normalmente.

Não tive a curiosidade de olhar a atual ainda pra ver aonde mexer.

Sobre errorsys em GUI, é simples: GUI fecha a janela, sem janela não tem mensagem de erro.
A não ser que a biblioteca GUI tenha alguma rotina própria.