WAPI v1.05 - Funções da API do Windows

[Pablo César]

Chr(12) pode fazer parte de um comando de configuração como argumento, seja ESC/P ou PCL.

Maligno, não pensou que esse grupo de códigos decimais ASCII: 02, 11 e 03 ou STX+VT+ETX possa também a ser algum comando de impressão ?

Não sei se essa questão de considerar <n> de linhas por páginas irá dar certo, visto que as vezes uma sequência de comandos de impressão poderiam estar excedendo o tamnho limite de caracter por linha.

Eu tenho entendido que o CHR(12) é U N I V E R S A L, isto é, sua equivalência comporta-se como salto de página (EJECT como quiser chamar) em TODAS as impressoras. Ao menos que eu estje e n g a n a d o.

[Maligno]

Maligno, não pensou que esse grupo de códigos decimais ASCII: 02, 11 e 03 ou STX+VT+ETX possa também a ser algum comando de impressão ?

Claro que já pensei. Por isso mesmo escolhi essa seqüência: não a encontrei em manual nenhum. Aliás, Chr(12) também não. Mas ele pode fazer parte de um comando, como disse. Agora, essa seqüência de três bytes não.

Não sei se essa questão de considerar <n> de linhas por páginas irá dar certo, visto que as vezes uma sequência de comandos de impressão poderiam estar excedendo o tamnho limite de caracter por linha.

Me refiro a arquivos texto crús, sem qualquer caractere de controle.

Eu tenho entendido que o CHR(12) é U N I V E R S A L, isto é, sua equivalência comporta-se como salto de página (EJECT como quiser chamar) em TODAS as impressoras. Ao menos que eu estje e n g a n a d o.

Não digo que esteja enganado, mas exagerando na importância da coisa. Como eu disse, Chr(12) poderia fazer parte de um comando. Aliás, qualquer tag de um único byte. Daí a minha escolha por três bytes.

Note que você está vendo dificuldade onde ela não existe. Se você vai ejetar uma página, como faz? Você faz algo do tipo: @ ... say Chr(12), não é? Eu já não faço isso. Eu uso minha função prtEject(), que executa esse mesmo @. Mas porque isso? Porque abstraindo o eject eu posso fazer qualquer coisa adicional que precisar, alterando apenas um único lugar do meu sistema inteiro. Analogamente, eu começo uma página com prtIniPag(). Ela nem precisa conter coisa alguma além de um return. Mas se no futuro eu precisar elaborar algum controle especial, eu tenho esse "escape" prontinho no programa todo. Meu esforço seria mínimo. Aí entra a inserção da tag de marcação de início de página. É nessa função que eu coloco o código que a insere. Matei o problema com poucos toques de teclado, apenas porque fui prevenido. Por isso que eu disse que, com um sistema de relatório bem elaborado você não tem trabalho nenhum, não importando qual tag e nem onde ela estará. Entendeu agora?

Veja que o Clipper, da forma como foi feito, é muito mal feito. Mas você, como programador, tem a oportunidade de melhorá-lo drasticamente fazendo uso desse tipo de técnica de abstração para a construção de sub-sistemas que tornam a tarefa de programação muito mais fácil, da mesma forma como poderia fazer em qualquer outra ferramenta mal feita.

[Pablo César]

A sua proposta de implementar impressão gráfica no WAPI é boa e não justificaria a utilização de um segundo aplicativo para desdobramento. Se bem que eu ainda sou a favor desse recurso por separado. Oras você sempre chamou atenção para desdobramento de funções ou "idéia básica da unicidade das funções" como você menciona na sua mensagem viewtopic.php?f=1&t=7640&p=42436#p42436. Você sempre disse que fica mais entendível e adequado separar as funções, (cada macaco no seu galho) mas neste caso você o está vinculando com as suas funções de impressão. (dá pra entender ?)

Gostei da estruturação de funções para relatórios. Poderias citar exemplos ? E listar as sub-sistemas mais relevantes que auxiliam seus relatórios ?

[Maligno]

Se bem que eu ainda sou a favor desse recurso por separado.

Porque separado se tudo é impressão? Você mudará para texto/gráfico/texto com base no conteúdo de um simples flag.

Oras você sempre chamou atenção para desdobramento de funções ou "idéia básica da unicidade das funções"

Você fez confusão nos termos. A característica da unicidade numa função é muito benéfica, mas quando é possível. Uma vez que existem vários níveis de funções (alto, médio, baixo nível), quando mais baixo o nível, mais preferível (e possível) é manter essa unicidade.

mas neste caso você o está vinculando com as suas funções de impressão. (dá pra entender ?)

Dá pra entender se você conseguir separar o que é nível de função do próprio termo função. Todo programa já começa com uma função. Mas por vezes a função é de alto nível, cujo conteúdo tem ação pontual. Só serve naquele ponto. Funções de biblioteca, por outro lado, tem um escopo mais abrangente. Nesse nível de função sim, é muito saudável manter a função executando uma única tarefa. No caso que discutimos, a impressão da WAPI, se você analisar os fontes, verá que eu sempre cuidei para manter essa característica. Mas eu sei que ainda não está do jeito ideal. Vou separar os fontes para melhorar mais ainda (não imaginava que ia crescer tanto).

Gostei da estruturação de funções para relatórios. Poderias citar exemplos ? E listar as sub-sistemas mais relevantes que auxiliam seus relatórios ?

Não são sub-sistemas no plural, mas no singular. Um sub-sistema tem por função auxiliar e facilitar o desenvolvimento de tarefas corriqueiras. É uma forma de abstrair funções que normalmente requerem ações repetitivas e tediosas. É como o sub-sistema GET. Ele é dispensável. Você até poderia fazer tudo sem ele, mas seria bem mais trabalhoso.

Para relatórios é a mesma coisa. Muito embora a maior carga de trabalho será sempre a impressão das linhas individualmente. De qualquer forma, muita coisa pode melhorar. Dois exemplos simples abaixo. Não são programas completos. São apenas exemplos.

O primeiro, sem o uso de um sub-sistema:

Código: Selecionar todos

set device to print
set printer on

lCab := .T.
while !EoF()
   if lCab
      lCab  := .F.
      nLins := 0
      CabecRel()
   end
   //
   @ PRow(),0 say "Registro: " + Str(RecNo())
   //
   if (++nLins) > 63
      RodapRel() // já com o Chr(12) para ejetar
      lCab := .T.
   end
   dbSkip()
end
if !lCab
   RodapRel()
end
//
set printer off
set device to screen

Agora usando um sub-sistema preparado para tornar o mesmo relatório mais dinâmico, fácil de ser alterado, apenas com a configuração do usuário:

Código: Selecionar todos

prtConfig() // o usuário escolhe a impressora, papel, etc
prtInit()   // o mecânismo de saída é preparado

while !EoF()
   if lCab
      lCab  := .F.
      nLins := 0
      prtInitPag()
      CabecRel()
   end
   //
   // O destino da impressão vai depender da configuração
   // A falta de coordenadas indica "coluna zero da próxima linha"
   prtOut("Registro: " + Str(RecNo()))
   //
   if (++nLins) > prtNroLins()
      RodapRel()
      prtEject()
      lCab := .T.
   end
end
if !lCab
   RodapRel()
   prtEject()
end
prtEnd()
//
// Se a saída for o vídeo, mostra o relatório
if prtOutVid()
   prtDispRel()
end

O exemplo 1 é mais ou menos como se costuma fazer sem um sub-sistema. O exemplo 2, com um sub-sistema preparado para trabalhar em vários modos, torna tudo mais fácil. Note que cada página tem uma chamada à prtInitPag(). É nessa função que eu poderia inserir um marcador de página ou preparar um texto adicional para o caso da saída ser o vídeo. É o mesmo caso de prtEject() que, normalmente, é o fim da página. Nele ou eu apenas insiro o Chr(12) tradicional ou, sendo vídeo, insiro um texto marcador de vídeo.
A impressão de linhas, também por função própria, me dá chance de produzir um filtro. Conforme a impressora configurada, posso utilizar este ou aquele conjunto de caracteres de controle. Na formatação do relatório tenho uma função que me informa a quantidade de linhas disponíveis na página. Posso configurar papel A4, Carta, formulário, meio-formulário, etc. O que for. Mas nada precisará ser alterado no relatório. Ao contrário do que aconteceria no exemplo 1, que fica bem mais limitado.

Basicamente é isso. Mas tem uma série de coisas a mais. Acho que cada um pode muito bem imaginar que várias facilidades podem ser criadas para tirar aquele monte de trabalho que normalmente se tem com relatórios.

A WAPI me ajudou bastante porque me deu flexibilidade para imprimir seletivamente sem me preocupar em modificar o relatório em si. Inclusive minha função prtConfig() conta com uma janela de configuração muito parecida com o diálogo de impressão que se vê nos programas Windows, como o Word, por exemplo.

[Pablo César]

Porque separado se tudo é impressão?

Discordo totalmente. Sabemos que essa questão de desdobrar o arquivo de impressão é uma função totalmente a parte da impressão. E se fosse possível desdobrar essa função do WAPI, poderia até ser utilizado para outros fins (como a utilização de relatorio de tabela para ser carregado no Excell, por exemplo). Ao final de contas, a execução de multiplas funções no WAPI não é feita com um único chamado ?. Entã... não iria atrapalhar em nada colocando essa função como mais uma opção independente sem estar intrínsica a função de impressão através do SPOOL.

Mas enfim... deixarei mais uma vez meus comentários de lado, visto que não chegaremos a lugar algum com isso. Foi apenas uma crítica que ainda pudera ter dado melhor funcionabilidade a essa nova função do WAPI.

[Maligno]

Sabemos que essa questão de desdobrar o arquivo de impressão é uma função totalmente a parte da impressão.

Não entendi nada do que diz esta frase. Se o arquivo é de impressão como pode ser à parte da impressão?

E se fosse possível desdobrar essa função do WAPI, poderia até ser utilizado para outros fins (como a utilização de relatorio de tabela para ser carregado no Excell, por exemplo).

Também não entendi o que isso quer dizer.

Ao final de contas, a execução de multiplas funções no WAPI não é feita com um único chamado ?

Não exatamente. Você está confundindo o meio de execução (WAPI.EXE) com a lista de switches que existe. Cada switch é uma função à parte. Não importa como é feito esse "chamado". Isso é um assunto à parte, irrelevante.

Entã... não iria atrapalhar em nada colocando essa função como mais uma opção independente sem estar intrínsica a função de impressão através do SPOOL.

A indicação para impressão em modo gráfico seria apenas um simples flag na linha de comando do switch -PRINT:. Até nem atrapalharia tanto criar outro switch, tipo -GRAPHPRINT:, por exemplo. Mas o destino dele seria o mesmo: o spool do Windows. Então, fica a pergunta: pra quê separar se posso usar um simples flag?

[Pablo César]

Eu estava me referindo ao procedimento interno do switch -PRINT que faz a impressão seletiva do WAPI. Confirmei o que eu estava supondo ser ao ler seu código fonte, no qual esse procedimento de "seleção de conteúdo a ser impresso" está dentro da mesma função que faz a impressão pelo spooler (função PRT_SendToSpooler). Deixemos de lado aquele faladeira toda sobre "unicidade das funções" emboar venha ao caso. O que eu estou tentado lhe dizer, é que seria até mais aproveitável ser separado o procedimento de "seleção de conteúdo a ser impresso" (que está dentro da função PRT_SendToSpooler) em função SEPARADA e até mesmo criando um novo SWITH para que esse procedimento venha acontecer em um arquivo temporário para impressão. Isso porque, você estaria acrescentando diversificando e conciliando recursos do WAPI, podendo até ser executado em conjunto ou simultaneamente com a função PRINT.

Pelo que eu ví e entendí do seu código fonte (na função PRT_SendToSpooler), você manda linha a linha o conteúdo do arquivo de impressão e (linha a linha) são enviado ao spool de impressão. Agora eu pergunto: Não seria mais rápido ou melhor enviar todo o arquivo pro spool ?. Qual seria a vantagem de manter isso assim ?

Outra coisa que eu te questiono é sobre os 5 parâmetros que foram adicionados ao swicth -PRINT. Sei que são necessário para compor a lógica para o procedimento de impressão seletiva. No obstante, se você tivesse aplicado outra técnica (como por exemplo aquela que eu exponho no tópico viewtopic.php?f=1&t=8105#p45550 que fala na criação de um segundo arquivo para impressão) você não iria necessitar de tantos parâmetros para fazer a impressão. Em vista da possibilidade de inserir mais um recurso de impressão gráfica, você mesmo está vendo que cada vez está mais complicado toda essa questão de impressão. Não seria mais um motivo para desdobrar procedimentos ?

[Maligno]

esse procedimento de "seleção de conteúdo a ser impresso" está dentro da mesma função que faz a impressão pelo spooler (função PRT_SendToSpooler).

E onde você acha que isso deveria estar? A função de impressão precisa saber o quê vai imprimir. Se olhar com calma, verá que existem duas funções de apoio. Uma destrincha (ou explode) a lista de páginas, obtendo e validando as seqüências de números. A segunda cria um índice em memória, que me permite encontrar facilmente cada página. Aí entra em ação a função de impressão que lê a lista de páginas e vai imprimindo uma a uma.

O que eu estou tentado lhe dizer, é que seria até mais aproveitável ser separado o procedimento de "seleção de conteúdo a ser impresso" (que está dentro da função PRT_SendToSpooler) em função SEPARADA

Gostaria que você me explicasse por quê seria mais aproveitável separar isso? E aproveitável pra quem?

Veja: a seleção do quê será impresso vem pelo argumento que representa a lista de números de páginas. De acordo com a filosofia do projeto, eu preciso dessa lista desmembrada. Isso é feito por uma função à parte, como já expliquei acima. Depois disso essa lista está pronta para ser lida na função principal. A cada número lido a página é encontrada no arquivo com a ajuda do índice montado por aquela outra função. Encontrada a página, ela é enviada para o spool. Ou seja, não dá pra separar coisa alguma.

e até mesmo criando um novo SWITH para que esse procedimento venha acontecer em um arquivo temporário para impressão.

Um novo switch pra quê exatamente? Não entendi isso. Qual seria a função dele? E pra quê um arquivo extra?

Realmente isso não me parece ter a menor lógica. Pra quê dar voltas e voltas se vou parar no mesmo lugar? Do jeito que foi feito é direto.

Isso porque, você estaria acrescentando diversificando e conciliando recursos do WAPI, podendo até ser executado em conjunto ou simultaneamente com a função PRINT.

Sua concepção me parece terrivelmente equivocada. A forma de trabalho que você está sugerindo, além de totalmente estranha (nem entendi muito bem), só faria acrescentar complexidade e dificuldade naquilo que não só é simples, como já está pronto e funcionando. Se eu percebesse na sua proposta algum ganho, até poderia acatar uma sugestão. Mas não é o que eu vejo.

Pelo que eu ví e entendí do seu código fonte (na função PRT_SendToSpooler), você manda linha a linha o conteúdo do arquivo de impressão e (linha a linha) são enviado ao spool de impressão.

Você não entendeu o código. Eu mando página a página.
Não confunda com aquela nova proposta de imprimir um arquivo texto crú, onde aí sim, cada linha seria lida individualmente e impressa sem qualquer tratamento. Mas isso ainda é apenas uma idéia.

Agora eu pergunto: Não seria mais rápido ou melhor enviar todo o arquivo pro spool ?. Qual seria a vantagem de manter isso assim ?

Poderia mandar o relatório inteiro, mas isso não produziria qualquer efeito benéfico em termos de velocidade. Não há uma grande vantagem em mandar página por página, mas em termos de facilidade de codificação, nem se compara, haja vista que nem sempre se quer imprimir tudo. E se o sujeito quiser imprimir apenas a páginas pares? Eu teria que ter dois blocos de código: um para imprimir tudo numa pancada só e outro pra imprimir de forma seletiva, página a página. Como não há ganho nisso, é melhor deixar assim.

Outra coisa que eu te questiono é sobre os 5 parâmetros que foram adicionados ao swicth -PRINT. Sei que são necessário para compor a lógica para o procedimento de impressão seletiva. No obstante, se você tivesse aplicado outra técnica (como por exemplo aquela que eu exponho no tópico viewtopic.php?f=1&t=8105#p45550 que fala na criação de um segundo arquivo para impressão) você não iria necessitar de tantos parâmetros para fazer a impressão. Em vista da possibilidade de inserir mais um recurso de impressão gráfica, você mesmo está vendo que cada vez está mais complicado toda essa questão de impressão. Não seria mais um motivo para desdobrar procedimentos ?

A quantidade de parâmetros é uma questão irrelevante. Eu poderia ter 50 parâmetros e isso não me atrapalharia em nada. Aí entra a biblioteca de abstração, cuja função principal é facilitar a sua vida, como usuário da WAPI. A camada extra de dificuldade a que você se refere, acredite, não está no tamanho da lista de argumentos. Isso é o de menos. Se meu problema fosse só esse, estaria contente.

Inserir o modo gráfico seria (teoricamente) apenas incluir mais um simples argumento. Na função principal de impressão eu talvez faça um desvio para a conversão, para depois enviar para o spool por ali mesmo. Mas há outras formas de fazer isso. Ainda não decidi nada. Mas pra você, usuário, isso é totalmente irrelevante.

Aliás, sendo irrelevante pra você, não entendo essa sua preocupação em "desdobrar procedimentos" dentro do WAPI.C. Pra você isso não importa. O que realmente importa é que funcione e bem, de forma transparente pra você. Isso, até onde foi feito, funciona sim. E continuará funcionando, mesmo com o acréscimo dos recursos que já mencionei. E os que não mencionei ainda, mas que são apenas idéias.

[Pablo César]

Esqueça tudo o que eu te falei ! No final de contas eu apenas sou um mero usuário, por quê cargas daguas teria que estar dando alguma opinião, não é ?

[Maligno]

Esqueça tudo o que eu te falei ! No final de contas eu apenas sou um mero usuário, por quê cargas daguas teria que estar dando alguma opinião, não é ?

Ao que parece, pelo destempero da sua mensagem, você está querendo impor e não sugerir uma alteração. Vendo que não conseguiu, me parece que se sentiu frustrado, irritado, contrariado e/ou desprestigiado.

Então, calma! Preste atenção e leia devagar o que tenho a dizer.

Eu disse que não entendo o porque de tanta preocupação em alterar algo que não lhe fará a menor diferença. Pelo menos eu acho que não fará. Ainda se eu tivesse entendido o que o motivou a fazer sua reivindicação, vá lá. Mas, honestamente, nem entendi muito bem. Agora, se você me apresentar um argumento válido (eu disse VÁLIDO) e forte o suficiente (eu disse FORTE), que me faça ver um caminho melhor (melhor MESMO), maravilha. Mudo minha opinião e atenderei sua reivindicação assim que possível, e mesmo à custa de uma carga maior de trabalho. Mas por enquanto isso não aconteceu. Você não me convenceu.

Mesmo sendo um mero usuário, se você tem uma sugestão e se dispõe a me fazer o favor de compartilhá-la, de antemão agradeço. Toda crítica, opinião ou sugestão é importante. Mas em primeira instância trata-se apenas de uma sugestão. Para que ela se materialize numa alteração, antes de tudo, vai ter que me convencer. Se não conseguir, de duas uma: ou você não está sendo claro o suficiente, ou eu realmente não vi nada de vantajoso na sua sugestão.

Note que se eu tivesse a mínima intenção de desmerecer sua sugestão, desprestigiá-lo ou fazer pouco caso, sequer me daria ao trabalho de escrever o tanto que escrevi. Em sinal de respeito ao seu pensamento e ao de todos do fórum, estou sempre pronto a ouvir qualquer um e a respondê-los com a maior paciência, educação e cordialidade, que são traços característicos da minha personalidade.

Mas não force a barra, que comigo não adianta.

[Pablo César]

não entendo o porque de tanta preocupação em alterar algo que não lhe fará a menor diferença.

Tudo bem, Maligno como eu disse e você disse, não estou mais aclamando qualquer mudança sobre a opção PRINT, ok ?.

Estou apresentando o que denominei "meu" TODO LIST, porque ainda considerei que há assuntos a serem resolvidos ou desconsiderados, dependendo a solução de tais pendências, é claro. Pois mesmo você não ter incluído certos itens, ainda não deixa de ser um TODO LIST e como cabe a você (que é pai da criança) estou disponibilizando para sua posterior avaliação de acordo com o seu ultimo TODO LIST:

• Controle de volume do som
• Inclusão da informação do diretório "iniciar" na informação do sistema
• Execução do WAPI no modo residente (codinome RES)
• Bloqueio do teclado e mouse em nível global (requer RES)
• Cancelamento de execução de WAVs (requer RES)
• Execução de sons em lote (funcionalmente melhor com RES)
• Apagamento seguro de arquivos (wipe file)
• Execução de atalhos de teclado, próprios do windows (ex: Alt+Enter)
• Criação de links para execução de programas
• Funções de FTP: list, delete, upload, download, etc...
• Criação de um help no estilo NG (Norton Guides)
• Criação de um programa demo completo, com todas as opções disponíveis
• Remover a dependência das bibliotecas CATools e NanFor
• Possibilidade (REMOTA) de função de verificação e retorno em arquivo do modo em que é exibida a sessão
• Possibilidade de função tipo "scheduler" para execução no TRAY quanto a verificação de existência de arquivo

Só para constar, porque ficou ainda sem resposta a minha msg viewtopic.php?f=1&t=4328&p=44536#p44536 não que esteja cobrando agora uma resposta. Prefiro que seja feito no tempo conveniente a sua disponibilização.

[Maligno]

Possibilidade (REMOTA) de função de verificação e retorno em arquivo do modo em que é exibida a sessão
Possibilidade de função tipo "scheduler" para execução no TRAY quanto a verificação de existência de arquivo

À todo list que redigi você acrescentou essas duas tarefas. A última é provável. Embora ela seja apenas um "gancho" para outras tarefas subseqüentes que, se não existirem, farão o schedulling inútil. Vou analisar melhor depois. Ela ficará(ia) em penúltimo lugar na lista.

Agora, a primeira dessas tarefas é algo mais complicado. Já pesquisei bastante a respeito. Ela não é prioridade, realmente, por quê a lista ainda está bem volumosa e, pelo que vejo, essa tarefa não representa uma necessidade real para muitas pessoas. Sinto muito, mas diante da dificuldade técnica, ela vai ter que ficar por último. Aliás, respondendo à sua pergunta: não tive tempo para analisar o Z.COM.

Mas a saber: estou terminando (aos poucos, conforme o tempo permite) o modo residente do WAPI.EXE, que já vai contar com mais algumas coisas, como o MUTEX para o Clipper, que fará o controle de execuções múltiplas da aplicação sem aquela "gambiarra" de antes. Aliás, o próprio fonte, pelo volume que já tem, está se tornando um empecilho. Vou segmentá-lo assim que terminar o modo residente.

[Pablo César]

Caro Maligno, apenas uma pergunta e possível sugestão. Será que há alguma função em C que permita alterar o direcionamento de saída de determinada impressora ? Para ser mais preciso mudar para impressão em arquivo, como mostra figura abaixo:



A idéia surgiu que se temos o nome das impressoras instaladas no Windows e ainda imprimir através da WAPI, talvez exista uma forma que pudesse alterar o flag do campo acima destacado (Propriedades da impressora/Portas), teria cómo ?

[Maligno]

Vou ter que pesquisar a respeito, pois aí, creio eu, já não tem mais a ver com o spooler do Windows. Fiquei curioso. Acho que no final de semana já devo ter uma resposta. Volto ao assunto.

[Tim9]

Quero imprimir usando o Wapi v1.03, já baixei e descompactei, como pretendo utilizar em cliente não vou usar o wapi.exe e sim o wapi.lib. Desculpem as minhas dúvidas mas sou leigo em impressão que fuja do trivial simples em lpt1 com clipper 5.2e e blinker 7, vejam as minhas dúvidas:

01. Neste programa uso os PCL para inicializar as impressoras Matricial ou Jato de tinta, a wapi dispensa este uso?

02. A Wapi reconhece qualquer impressora local em lpt1 (não preciso mais inicializar cada uma) ?

03. Para compilar com blinker só preciso copiar para o clipper5\lib a wapi.lib ou também os .h e .ch para clipper5\include, etc. enfim quais os arquivos que devo compilar junto com meu programa ?

04. Entendi que sempre devo gerar meu relatório em arquivo texto para depois imprimir. É isso mesmo?

05. Qual a sintaxe para imprimir com a wapi?

Aguardo e antecipo meus agradecimentos pela atenção, mais uma vez pedindo desculpas pela ignorância no assunto.