PC Toledo

Como também faço uso deste tipo de função (para relatorios impressos, ou rotinas de edição), digo que especialmente nestes casos, dá na mesma. Para exibição em tela aí sim, use o ordscope() para te facilitar a vida.

É como o Alanimo falou. Especificamente nesse caso acho que não fará diferença. Mas nas outras ocasiões sim.

O que o OrdScope faz é delimitar os dados no DBF que o sistema enxergará. Assim, vc pode ter um DBF com milhões de registros, mas somente aqueles que estiverem dentro da area delimitada serão considerados.

Jânio

Luciaono,
Resumindo o ORDSCOPE() é um SET FILTER TO , porem mil vez mais rapido...realiza filtro sem lentidão.

Janio,
Se quise tenho uma rotina para visualização de TXT para HWGUI que pode enviar depois para emial, PDF e WORD, alias tenho mais de. Tenho uma aqui que usa o PREVIEW da HBPRINTER e manipula os CHR(15) , CHR(18) , eject e outros caracter especial...

Grande Sygecom,

Agredeço, porém o problema continuará o mesmo, ou seja, só posso exibir o TXT depois que este estiver com todos os dados.

Preciso que vá GERANDO a medida que for EXIBINDO.

Jânio

Janio, nesse caso nem o THREAD vai ajudar, o THREAD apenas vai deixar sua app livre em quanto roda a rotina do relatorio....ou seja como se fosse um segunda app rodando a rotina. mas o tempo vai ser o mesmo e só vai mostrar o TXT depois de criado. se quiser lhe mando uns exemplos de Mult-thread.

Nada disso. O que o Janio quer é perfeitamente possível de se fazer, e só poderá ser feito com threads. Uma thread exibe parte do relatório que já está pronto no arquivo, em primeiro plano. Enquanto isso, outra thread continua montando o relatório em background. Só que será preciso montar um controle de eventos.

o que o Maligno disse seria a solução

uma theread gerando o relatorio no dbf
outra fazendo um browse no dbf.


o problema e fazer o codigo para isto

Acho que botar DBF no meio é um artifício desnecessário. Um visualizador de TXT é algo muito simples e rápido de fazer. Inclusive, há código pronto em Clipper que pode ser aproveitado.

Quanto ao código envolvendo threads, é coisa realmente que dá um pouco de trabalho e até pode assustar a princípio, mas não é um bicho-papão. Agora, vale o ditado: "só se pode terminar depois de começar".

sygecom escreveu:se quiser lhe mando uns exemplos de Mult-thread.

Quero sim!

Jânio

Se possivel ,cola aqui os exemplos , temgente acompanhando o tópico ....

Maligno escreveu:Nada disso. O que o Janio quer é perfeitamente possível de se fazer, e só poderá ser feito com threads. Uma thread exibe parte do relatório que já está pronto no arquivo, em primeiro plano. Enquanto isso, outra thread continua montando o relatório em background. Só que será preciso montar um controle de eventos.

O que eu quiz dizer é que mesmo assim não vai ser instanteneo com um DBF, conforme o exemplo do Janio, mesmo em thread separada ele levara o mesmo tempo para concluir todo o relatorio...

Eu faria o teste com thread como DBF, e iria mostrando em um tbrowse, e a cada movimento ou cada x segundos ia dando um refresh() até que o mesmo estaja completo...claro que usando um dbf temporario onde uma thread estaria com o dbf SHARED e a outra como READONLY.O problema vai ser os usuarios apresadinhos...que vão dando logo os page-down e não vai esta preenchido todo o tbrowse....

Vou ver se coloco um exemplo aqui no forum !!!

sygecom escreveu:O que eu quiz dizer é que mesmo assim não vai ser instanteneo com um DBF, conforme o exemplo do Janio, mesmo em thread separada ele levara o mesmo tempo para concluir todo o relatorio...

Entendi o que você quis dizer agora. O tempo para a geração total do relatório será o mesmo de antes. Mas não é essa a questão. Discordei do que você disse antes:

mas o tempo vai ser o mesmo e só vai mostrar o TXT depois de criado

Aí realmente está errado. A função das threads é justamente permitir a visualização do relatório enquanto ele estiver sendo gerado.

Ou, conforme a segunda idéia que o Janio lançou: gerar o relatório por demando. Em qualquer um dos casos é possível. Aliás, é possível até em Clipper mesmo.

Eu faria o teste com thread como DBF, e iria mostrando em um tbrowse, e a cada movimento ou cada x segundos ia dando um refresh() até que o mesmo estaja completo...

É uma idéia. Perfeitamente válida. Mas ainda acho que TXT é muito melhor e mais dinâmico. Mas isso vai do gosto de cada um.

Pois, eu pensei no DBF por causa dos refresh() no tbrowse,nunca testei, mas visualizando um TXT pelo TBROWSE() tem como usar o refresh() ? se tiver como ai pode ser direto com TXT mesmo....

Visualizar TXT pelo TBrowse implica em exportar o TXT para um DBF ou gerar o relatório diretamente pra DBF (um artifício que provavelmente ainda terá de ser implementado). Até funciona, mas é um procedimento que poderia ser dispensado. Além do que, manipular TXT é tão fácil que dá pra fazer um visualizador numa tarde. Mas tem coisa pronta por aí. É só recompilar. Desde que não tenha funções em C, como alguns que já vi.

Aliás, existe grátis no "The Oasis" uma LIB de tratamento de TXT que permite manipulá-lo como se fosse DBF (GOTO, SKIP, GOTOP, etc). É só recompilar pra XHarbour e montar o visualizador usando esse recurso. Eu fiz meu visualizador em Clipper mais ou menos desse jeito e ficou muito legal.

Maligno escreveu:Visualizar TXT pelo TBrowse implica em exportar o TXT para um DBF ou gerar o relatório diretamente pra DBF (um artifício que provavelmente ainda terá de ser implementado).

Negativo, olhe o exemplo desse tbrowse que visualiza arquivo TEXTO:
https://pctoledo.org/forum/viewtopic.php?t=3954