PC Toledo

Bom dia, amigos!

Em meus sistemas costumo usar um loop Do While...EndDo para imprimir relatórios. Só que tenho um problema: quando mando relatórios de dez ou quinze páginas para a impressora e ela trava ou o papel contínuo enrosca na nona página, por exemplo, tenho de mandar imprimir o relatório inteiro de novo. Isso deixa a mim e aos usuários do sistema furiosos! :?

Como eu posso fazer para, por exemplo, poder escolher o intervalo de páginas a imprimir ou a partir de qual página continuar imprimindo?

Chequei a pensar em mandar a impressão para arquivo (fl001.txt, fl002.txt, fl003.txt, etc) e, depois, mandar imprimir cada um desses arquivos separadamente. Mas, como já tenho uma rotina que manda o relatório inteiro para um arquivo .txt destinada à visualização na tela, gostaria de aproveitar a mesma rotina para a impressão.

Alguém tem alguma sugestão?

Labaroazul

Utilize a lib. Wapi do colega maligno, ele fiz uma lib boa mesmo, e a disponibilizou para todos nos; em este foro.

Boa sorte e muito obrigado a maligno.

Pode também utilizar programas externos de terceiros, como USB.EXE, NoDosImp, DosPrinter e autros.

Adalberto escreveu:Pode também utilizar programas externos de terceiros, como USB.EXE, NoDosImp, DosPrinter e autros.

Esses programas têm o mesmo recurso da WAPI, de imprimir listas de páginas, apenas números pares ou ímpares, impressão reversa, etc?

Se o sistema do colega não tiver um controle de páginas (o qual eu acredito não ter) não adianta estes programas externos, aliás seria bom não depender deles.
A solução, a meu ver, está em quebrar este relatório em etapas. Por exemplo: uma listagem de produtos de diferentes departamentos ou marcas, ou mesmo pela ordem alfabética. Não é difícil não !!!

alaminojunior escreveu:Se o sistema do colega não tiver um controle de páginas (o qual eu acredito não ter) não adianta estes programas externos, aliás seria bom não depender deles.

Até gostaria de não depender deles. Mas isso é outra história. O fato é que com a WAPI você não precisa controlar o número de páginas. Basta iniciar a página com uma tag. No momento da impressão você diz quais/de_que_forma quer imprimir e a WAPI faz o resto. Mas é claro que o ideal é você numerar as páginas. Mas é opcional.

A solução, a meu ver, está em quebrar este relatório em etapas. Por exemplo: uma listagem de produtos de diferentes departamentos ou marcas, ou mesmo pela ordem alfabética. Não é difícil não !!!

Pelo problema exposto pelo colega, que quer, por exemplo, imprimir da página X até o fim, há apenas duas formas: ou manda tudo pra arquivo e encontra a página X para imprimir a partir dali ou gera o relatório e inicia a impressão quando encontrar X.

Mais fácil seria usar um recurso como a WAPI, que indexa o relatório inteiro e imprime da forma que você quiser, por mais esdrúxula que seja. Você só precisa de duas coisas simples: marcar o início de cada página com a tag e direcionar a saída pra um arquivo. Depois é só executar uma função que passe isso pra WAPI.

Coloque na entrada de parâmetros do seu relatório a pergunta de quais páginas serão impressas.
Quando o contador de páginas entrar nessa faixa, vc ativa o SET PRINT ON e quando terminar a faixa, coloque em SET PRINT OFF.

gvc escreveu:Quando o contador de páginas entrar nessa faixa, vc ativa o SET PRINT ON e quando terminar a faixa, coloque em SET PRINT OFF.

Eu tomei a decisão de NUNCA mais utilizar o SET PRIN ON, principalmente numa rede de WINXP, gosto de criar SEMPRE arquivo textos porque ele dão possibilidade de re-utilizá-los sem a necessidade de re-processamento algum. Não uso a opção do WAPI para escolher a paginação, pois não é sempre que é necessário o uso desse recurso e visto que o WAPI não imprime em modo gráfico como é necessário em alguns casos, daí então utilizo o USB.EXE do Heveraldo. Mas irei readaptar todos os módulo que fazem relatórios e compilá-los em xHarbour. A questão de paginação, acredito que a melhor saida é desdobrar em um SEGUNDO arquivo o que terá que imprimir, conforme seleção prévia do usuário (recurso que terá que ler linha a linha, procurando alguma caracteristica que sirva de identificação) e daí mandar imprimir conforme o tipo da impressora.

[Pablo]
Transcrevo: "Eu tomei a decisão de NUNCA mais utilizar o SET PRIN ON, ..."

Calma. Eu só coloquei algo que o nosso amigo labaroazul pode ter como solução.
Se vc colocar SET PRINTER TO <nome do arquivo>, tudo o que for impresso vai para o arquivo. Então o SET PRINT ON/OFF vai controlar o que deve ou não ir para o arquivo. Assim como pode mandar direto para impressora.
Coloquei essa opção procurando evitar de montar o arquivo, ler linha por linha e imprimir somente o especificado pelo usuário.
Deixo claro que isso é uma solução simples e acredito que atenda a solicitação do labaroazul.

[labaroazul]
Vc conseguiu acertar o relatório?

gvc escreveu:Calma. Eu só coloquei algo que o nosso amigo labaroazul pode ter como solução.
Se vc colocar SET PRINTER TO <nome do arquivo>, tudo o que for impresso vai para o arquivo.

Ahhh sim dessa forma realmente é bem prático fazer, no entanto irá precisar criar arquivos com nomes diferentes para cada seção selecionada ou setar o ALTERNATE de forma que adicione e não sobre-escreva no mesmo arquivo, mas para isso terá que criar uma varável lógica para que abra o ALTERNATE uma única vez de forma sobre-escrita e o resto de forma ADDITIONAL.

Eu escreveu:Eu tomei a decisão de NUNCA mais utilizar o SET PRIN ON, ...

Mas não se sinta criticado amigo GVC, me desculpe se deu a entender isso. O que eu quis realmente ressaltar é que eu não gosto de utilizar o SET PRIN ON direto na impressora (isso porque existe vários tópicos com problemas de impressão em rede WINXP), na minha concepção esse procedimento restringe-se a poucas situações em que possa ser utilizado de forma que não degrade a impressão e tráfico na rede. Mas é claro que é válido sua idéia pois é uma das práticas mais simples de criação de arquivo, no entanto requer um certo tratamento.

Aproveitando esta questão, gostaria de fazer uma sugestão ao colega Maligno sobre a função de impressão seletiva de página. Mas que prefiro comentar no tópico correspondente:

viewtopic.php?f=1&t=4328&p=45468#p45468

[Pablo]
Acho que vc não entendeu então o que eu coloquei para solucionar o problema.
Com o SET PRINT ON/OFF eu controlo o que irá para a impressora ou arquivo.
Então o sistema entra em uma página que não deve ser impressa, eu coloco em SET PRINT OFF.
Entrou em uma página que deve ser impressa, eu coloco em SET PRINT ON.

Com o SET PRINTER TO <porta>/<arquivo> eu determino para onde será enviado o relatório.

Eu acredito que sim, que eu entendí bem a sua idéia. Não sei se você concorda ou não mas enviar um arquivo de impressão para ser impresso numa rede com WINXP nas máquinas, você obterá melhor resultado de impressão do que mandando através do SET PRIN ON para impressora. Por isso eu mencionei: "Eu tomei a decisão de NUNCA mais utilizar o SET PRIN ON, ...", não sei se você concorda. Então por isso eu discordei e fiz o meu comentário (e minha notação foi com a intenção de fazer de forma construtiva).

Com o SET PRINTER TO <porta>/<arquivo> eu determino para onde será enviado o relatório.

Mas se o usuário tiver necessidade de enviar dois ou mais blocos de impressão, isto é: página 12, 15 até 18. Daí você direcionando o SET PRIN para ARQUIVO você terá que dar nomes diferentes para depois imprimi-los pelo seus nomes ou então terá que utilizar o SET PRINTER TO <arquivo> ADDITIVE quando mandar imprimir em arquivo as páginas 15 a 18.

Eu tentei entender a sua idéia Gilberto, você poderia exemplificar, por favor ? Assim visualizamos melhor a sua idéia.

[Pablo] Com o set printer to vc define o arquivo/impressora.
Com o set print on/off vc liga/desliga a saida para impressora ou arquivo. Com isto vc não precisa criar mais de um arquivo/impressão.

Tudo bem Gilberto, eu não diria que essa indicação não funcionasse, mas ainda discordo por duas questões de peso:

1. Porque a impressão direta em rede WINXP, sem a criação de arquivo de impressão, torna-se lenta (amarrada).
2. Fazer um procedimento de seleção em cada relatório através do SET PRINT ON/OFF irá demandar muito trabalho.

Acho que uma boa saída é fazer um aplicativo para desmembrar o arquivo de impressão e daí sim, fazer o que quiser com ele: imprimir/visualizar/editar, etc. Assim como indiquei ao Maligno no tópico do WAPI viewtopic.php?f=1&t=4328&p=45484#p45484

Mas enfim, essa é a minha opinião. Você Gilberto ainda não disse se discorda ou não sobre a degradação do uso do SET PRINT ON direto à impressora em rede WINXP.

E quero salientar que este tema de impressão seletiva de páginas, é muito importante e gostaria que seja extendido o debate para chegarmos ao melhor consenso sobre este tema. Pois quantas vezes o meu cliente me perguntou como faria para imprimir de forma seletiva um relatório muito extenso. Quando são etiquetas, por exemplo, é fácil determinar de tal número até tal número, mas quando são registros que variam a sua ordem, daí complica um tanto.

[Pablo]
Teste este código. Veja que só é criado um arquivo e que o set print on/off funciona como um registro (hidraulico) para determinar se a saida dos números deve ir para o arquivo ou não.
Toda a saída gerada ira para um único arquivo, não sendo necessário criar vários.
Assim o labaroazul pode usar isso para gerar o relatório todo no processo e só mandar para o arquivo texto o que realmente deve ser impresso.
Entendo que isso ira resolver o problema exposto.

Funciona mesmo como o esperado Gilberto. Mas esse seu exemplo é o mesmo que condicionar a utilização do "? i" como exponho abaixo:
Independente da utilização do SET PRINTER TO <arquivo>, claro que sempre iria dar certo pela condição aplicada. A questão principal é qual método utilizar para desdobrar o arquivo, uma das sugestões foi a do Maligno no seu tópico WAPI sobre impressão de página seletiva utilizando-se a contagem de linhas. Eu questionei que isso seria possível, sempre e quando o arquivo não contivesse comandos de impressão, visto que as vezes uma sequência de comandos de impressão poderiam estar excedendo o tamanho limite de caracter por linha. Mas confesso que isso também não é impecilho algum. Pois podemos ler o arquivo em baixo nível linha a linha, procurando pelo caracter CHR(13) que compõe a quebra de linha e esta linha não necessáriamente precisa ser de tamanho exato (isso quando houverem caracteres de controle de impressão). Outro fator primordial: é saber quando começa cada página e quando termina. A minha sugestão foi considerar o CHR(12) que TODO mundo usa ao invés de TAGs como é utilizado a função PRINT do WAPI. Eu sou contra o uso das TAGs porque nem todo mundo possui uma estrutura como a que sugere o Maligno. Por isso, sou a favor de utilização de um aplicativo externo (ou até mesmo função) que trate o arquivo de impressão, ora porque desta forma a adaptação em sistemas que ja foram desenvolvidos seria menor do que alterar todos os códigos para inserção de TAGs que não foram previstos. Além do que ainda corre o risco de que não possa ser utilizado outro aplicativo de impressão como por exemplo o USB.EXE do Heveraldo e que não iria proceder adequadamente com as tags sugeridas pelo WAPI.

Então resumindo:

- Elaboração de aplicativo ou função interna para tratamento de desdobramento de arquivo de impressão.
- Nesse aplicativo deverá ter em conta:
1) Nº de páginas conforme quantidade de CHR(12)
2) Obter em tela as páginas que deverão ser impressas através informação do usuário e validar a informação.
3) Identificar localizando inicio e fim de cada página tendo como guia o CHR(12)
4) Direcionar em arquivo secundário, todas as linhas que pertencerem a página selecionada
- Direcionar arquivo secundário para o spool de impressão (seja por comando do Clipper ou mediante aplicativo externo)

O verdadeiro desafio é cómo fazer essa questão nº 3 e logo pensei em algo bem prático que poderá ser utilizado pelo usuário quantas vezes precisar. E a minha sugestão é:

No item 2, poderia ser apresentado em tela todo o relatório, com comandos de impressão inclusive (podendo ser usado um TBROWSE) com uma coluna fixa a esquerda, exibindo o número de cada linha, que servirá como guia para que o usuário possa informar de qual linha até que linha, isto é, informar inicio e fim. Desta forma fica muito fácil gerar o arquivo secundário, pois se o usuário tiver a necessidade de imprimir vários blocos será questão de executar tantas vezes precise até finalizar a impressão de todos os blocos. Claro que também não irá ser necessário a leitura do caracter CHR(12) nem muito menos TAGs alguma, pois o relatório esteja composto, pronto para imprimir com seu comandos de impressão inclusive. O único que terá que ser levado em conta o CHR(13) indicando o final de cada linha para importar em um DBF temporário e ser exibido em TBROWSE.

Acho que essa é a melhor idéia que surgiu para atender esta questão de impressão por bloco. Eu estou satisfeito, se alguém quiser colaborar com alguma idéia, será bem vindo.