PC Toledo

a lixeira como repositório... Não longe disso !. É que neste meu caso, o mais indicado não é guardar o arquivo. O mais indicado é DELETAR, mesmo. Ora porque para o usuário REFAZER o seu conteúdo seria mais fácil do que aplicar o FILEFIX (por exemplo) para recuperar o arquivo DANIFICADO.

E tem mais um exemplo. No meu sistema tenho uma opção de criar (não é CAMPO MEMO... hehehe) arquivos "quase que temporários", são arquivos para dar um recado, é feito através do MEMOEDIT e é guardado em pasta exclusiva para isso. Uma vez lido a mensagem, pergunta se deseja apaga-la.

Outro exemplo que eu tive no meu sistema. Tenho uma opção onde o usuário pode imprimir o movimento mensal. Para isto o sistema dispõe em ACHOICE os meses que ele tem acumulado e que são arquivos conforme cada mês. Nesta função que rege o ACHOICE também disponibilizo a opção de deletar esses arquivos que são compostos pela nomenclatura (MES/ANO). Ja teve cliente, que me perguntou se poderia ser recuperado, porque ele deletou. Já viu... foi triste para mim dizer... que não dava mais, a não ser que recorresse ao BACKUP.

Veja Maligno, que eu não te estou pedido para satisfazer a minha necessidade apenas. Acho que apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira. Isto é um conceito, diferente para nós que trabalhamos em DOS.

Por outro lado, fazer uma pasta como repositório, tem também seus inconvenientes. Para os usuários deleixados, a pasta em certo tempo iria ficar com arquivos e mais arquivos e demandar uma rotina para eliminá-los por data. Sei que não soa mal, mas depende para que caso e quais os motivos.

E depois de tudo, sua biblioteca está ficando muito completa e não viria mal essa nova opção.
Um clip-abraço :)Pos

Ja teve cliente, que me perguntou se poderia ser recuperado, porque ele deletou. Já viu... foi triste para mim dizer... que não dava mais, a não ser que recorresse ao BACKUP.

Não é vergonha sua. Quem apagou foi ele.

Acho que apagar um arquivo da forma que o WINDOWS o faz, isto é colocando-o na lixeira. Isto é um conceito

Ah, sim. Não discordo disso. Seria um recurso a mais.

Para os usuários deleixados

O desleixo do usuário é responsabilidade dele. Sua responsabilidade seria apenas indicar um filtro de backup para excluir estes arquivos.

iria ficar com arquivos e mais arquivos e demandar uma rotina para eliminá-los por data.

Algumas poucas linhas de código, que seria executado ao iniciar o programa.

E depois de tudo, sua biblioteca está ficando muito completa e não viria mal essa nova opção.

Não descartei. Está anotado na agenda do WAPI. Só que vai demorar um pouco. Estou fazendo o WAPI residente e isso envolve multi-trheading. Isso toma mais tempo que o normal. Depois disso, na seqüência, ainda tem o bloqueio de desktop e teclas.

[]'s
Maligno
http://www.buzinello.com/prg

Sei que você anda ocupado MALIGNO. Mas teria como responder pro colega esta questão do https://pctoledo.org/forum/viewtopic.php?t=5714

Um clip-abraço :)Pos

Caro MALIGNO,

Recebeu a minha mensagem privada sobre a resposta que recebí sobre a questão do modo da sessão (linguagem C) ?. Verificando o conteúdo indicado, encontrei este exemplo:
http://msdn2.microsoft.com/en-us/library/ms685035.aspx
Mas não sei se irá clarear alguma coisa. Mas eu tentando entender, ocorreu-me uma idéia:

Será que verificando/obtendo os eventos do mouse, para cada sessão houvera alguma diferença entre sessão (modo TELA-CHEIA e JANELADO) ?

É apenas uma idéia e talvez pudesse ser trabalhada. Pois uma das diferenças entre os modos (TELA-CHEIA e JANELADO) no modo TELA-CHEIA, não possue MOUSE do WINDOWS. isto poderia ser uma indicação para saber em que modo estaria. O que você acha colega ?.

Um clip-abraço :)Pos

Pablo César escreveu:Será que verificando/obtendo os eventos do mouse, para cada sessão houvera alguma diferença entre sessão (modo TELA-CHEIA e JANELADO)?

Nem digo que seja impossível. Muitas vezes um efeito colateral qualquer até pode resolver um problema. O difícil é encontrar tempo pra estudar e pesquisar uma forma de conseguir isso.

Não quero dar esperanças a você, mas naquele link que você me passou, há uma entre as 5 alternativas que encontrei pra detectar o modo da janela. Uma delas é até interessante. Porém, ela tem dois defeitos: funciona, mas só no XP. E segundo: nem sempre funciona no XP, pelos testes que fiz. Não sei se é bug da Microsoft, do meu Windows ou meu. )) Mas não deu tão certo como deveria.

Aliás, também não quero desanimá-lo, mas você já parou para pensar sobre o assunto e percebeu que detectar o modo da janela é apenas parte do problema? O ideal seria detectar o modo da janela e sempre forçá-lo para um ou outro modo, de acordo com sua preferência. Detectar o modo não garante a comutação automática. O problema, aliás, nem está na comutação. Isso é bem fácil. O problema está na detecção E comutação automática. A NTVDM não possui uma mensagem específica para a troca de modos, pelo que já pude apurar. Se tivesse, o próprio WAPI talvez pudesse ter uma thread que ficasse monitorando a pilha de mensagens do Windows. Portanto, SE houver um meio eficiente de detectar o modo, você precisaria criar uma "task" em background no próprio Clipper. Isso certamente elevaria seu consumo de CPU às alturas.

[]'s
Maligno
http://www.buzinello.com/prg

Maligno escreveu:Nem digo que seja impossível.

Logo que postei e ví a demora em você responder... pensei... acho que o Maligno, algo encontrou !!!

Maligno escreveu:Muitas vezes um efeito colateral qualquer até pode resolver um problema. O difícil é encontrar tempo pra estudar e pesquisar uma forma de conseguir isso.

Bom isto já é um começo. E quanto o menos esperamos, vemos numa coisa simples a solução.

Maligno escreveu:... naquele link que você me passou, há uma entre as 5 alternativas que encontrei pra detectar o modo da janela. Uma delas é até interessante.

Sei que você ainda está estudando a forma mais conveniente e testando as opções. Mas se precisar que seja respondido e aproveitar para um pedido de opinião, sinta-se livre de fazé-lo diretamente para a pessoa ou até mesmo para que eu traduça e/ou envie por email.

Maligno escreveu:Porém, ela tem dois defeitos: funciona, mas só no XP. E segundo: nem sempre funciona no XP, pelos testes que fiz.

Este sempre foi um KARMA para mim, por algumas funções do API, não funcionarem em WIN98.

Maligno escreveu:...não quero desanimá-lo, mas você já parou para pensar sobre o assunto e percebeu que detectar o modo da janela é apenas parte do problema? O ideal seria detectar o modo da janela e sempre forçá-lo para um ou outro modo, de acordo com sua preferência.

Sim, seria muito importante se você pudesse reproduzir as teclas ALT-ENTER. Mas se não houver possibilidade e conseguir detectar o modo, como eu disse em mensagens anteriores, eu me conformaria com apenas dar uma mensagem pro usuário para que acionasse a telca ALT-ENTER para mudar de modo, no caso que a detecção não seja a pretendida.

Maligno escreveu:Não sei se é bug da Microsoft, do meu Windows ou meu

Se precisar que seja testado todas as vezes que você achar uma nova versão, pode contar comigo. Me mande por email e eu teste nos dois WINDOWS (98 e XP).

Maligno escreveu:Portanto, SE houver um meio eficiente de detectar o modo, você precisaria criar uma "task" em background no próprio Clipper.

Não entendí essa parte. Essa task é para que fique residente e faça alguma verificação ?.

Também outra questão que não entendí, quando você menciona em mensagem anterior:

Estou fazendo o WAPI residente e isso envolve multi-trheading.

Qual seria essa finalidade ?. Seria para tratar a questão de bloqueio do teclado para a questão do ECF ?. Será que o aplicativo para atender essa questão de "residente", não deverias separa-la do WAPI ?. Acho estranho ver o WAPI como residente, não carregaria coisas a mais na memória ?. Digo isto, porque para o caso de aplicativos residentes, sempre é apenas UM aplicativo ESPECÍFICO e não multivalentes como é o WAPI.

Tenho certeza que você irá descobrir a forma mais adequada de detectar o modo e possivelmente a reprodução de acionamento das teclas ALT ENTER.

Boa sorte colega, pena que não poderei estar muito tempo sem dormir. Pois estou com uma gripe que tira toda as minhas forças... vou descansar, mas amanhã estarei desde cedo (se DEUS permitir, é claro).

Um clip-abraço :)Pos

Logo que postei e ví a demora em você responder... pensei... acho que o Maligno, algo encontrou !!!

Eu estava trabalhando. Aliás, só consegui acabar agora, às 4 da manhã.

E quanto o menos esperamos, vemos numa coisa simples a solução.

O diabo é que essas coisas simples não são fáceis de encontrar.

Este sempre foi um KARMA para mim, por algumas funções do API, não funcionarem em WIN98.

É como eu já disse há um bom tempo: não alimente muitas esperanças de ver esse problema resolvido da forma ideal.

seria muito importante se você pudesse reproduzir as teclas ALT-ENTER. Mas se não houver possibilidade e conseguir detectar o modo, como eu disse em mensagens anteriores, eu me conformaria com apenas dar uma mensagem pro usuário para que acionasse a telca ALT-ENTER para mudar de modo, no caso que a detecção não seja a pretendida.

Também como já disse antes: a injeção de um código de Alt+Enter no Windows não refresca nada, já que este atalho tem função comutativa. Não há utilidade nisso. Aliás, se existisse um atalho qualquer que comutasse especificamente para modo fullScreen, também não seria uma boa solução, já que isso, pra funcionar, imporia um overhead considerável no programa Clipper.

Se precisar que seja testado todas as vezes que você achar uma nova versão, pode contar comigo. Me mande por email e eu teste nos dois WINDOWS (98 e XP).

Obrigado. Mas Isso não chega a ser problema, já que eu próprio disponho de todas as versões do Windows, a exceção do Me. É só montar uma máquina virtual no VMware.

Maligno escreveu:Portanto, SE houver um meio eficiente de detectar o modo, você precisaria criar uma "task" em background no próprio Clipper.

Não entendí essa parte. Essa task é para que fique residente e faça alguma verificação ?.

Por "task" no Clipper, entenda: uma função que execute em background. Pra evitar que o usuário mude para o modo windowed você precisaria de uma função rodando em background no Clipper. Essa função, ao detectar a troca de modo, comutaria de volta para o modo fullScreen. Isso, logicamente, imporia um overhead no sistema e o consumo de CPU subiria bastante.

Também outra questão que não entendí, quando você menciona em mensagem anterior:

Estou fazendo o WAPI residente e isso envolve multi-trheading.

Qual seria essa finalidade ?. Seria para tratar a questão de bloqueio do teclado para a questão do ECF ?.

Exatamente. É o seguinte: para bloquear o teclado eu preciso instalar um hook no manipulador de eventos de teclado do Windows. Mas isso só é possível dentro da mesma tarefa. Portanto eu tenho que manter o WAPI na memória. Se ele morre depois de instalado o hook, o hook morre junto e a monitoração deixa de existir. Quando disse que isso envolve multi-threading, eu quis dizer que com o WAPI residente algumas tarefas poderão ser executadas ao mesmo tempo, com a criação threads. Com o WAPI transiente nada disso será possível. E hoje ele ainda é transiente. Mas mudá-lo para residente é algo que eu já previa desde o começo. Só não fiz antes porque a coisa tem que ser melhor planejada. Também com relação às funções de abstração e à possibilidade de dupla instância do programa Clipper.

Será que o aplicativo para atender essa questão de "residente", não deverias separa-la do WAPI ?. Acho estranho ver o WAPI como residente, não carregaria coisas a mais na memória ?.

O WAPI é um sistema atômico. Não dá pra dividir. Mas a memória consumida é uma mixaria. Nem se preocupe com isso. ))

Digo isto, porque para o caso de aplicativos residentes, sempre é apenas UM aplicativo ESPECÍFICO e não multivalentes como é o WAPI.

Não pensei ainda na possibilidade de multiplas instâncias do WAPI. É até uma possibilidade, mas tenho quase total certeza de que o melhor é bloquear isso. Acho que a instância única seria melhor, até porque, uma vez multi-threading, cada tarefa processaria em seu próprio espaço, separadamente. O bom disso é que bloquear re-instanciamento de aplicacão Windows é bem mais fácil.

Pois estou com uma gripe que tira toda as minhas forças...

Estimo melhoras.

[]'s
Maligno
http://www.buzinello.com/prg

Fiquei acordado até pouco depois da meia noite, fico ancioso pensando em como eu poderia ajudar você. Esse link que eu tinha te passado na minha mensagem anterior, foi encontrada de dentro de aquelas 3 Títulos que eu havia te mandado por MP. Assim que é bastante extenso a documentação da MS.

Maligno escreveu:se existisse um atalho qualquer que comutasse especificamente para modo fullScreen, também não seria uma boa solução, já que isso, pra funcionar, imporia um overhead considerável no programa Clipper.

E se eu usasse o WAPI.EXE diretamente na linha de comando. No meu caso específico, com meu sistema modular, tranquilamente poderia sair do aplicativo-Clipper (mas não sair da sessão) executar o aplicativo GUI e depois executar o WAPI.EXE de dentro do arquivo .BAT que gerencia todas as chamadas do meu sistema. Será que assim não sobre-carregaria pois estaria sendo executado na linha de comando.

Maligno escreveu:Por "task" no Clipper, entenda: uma função que execute em background. Pra evitar que o usuário mude para o modo windowed você precisaria de uma função rodando em background no Clipper. Essa função, ao detectar a troca de modo, comutaria de volta para o modo fullScreen. Isso, logicamente, imporia um overhead no sistema e o consumo de CPU subiria bastante.

Puxa ! Seria genial isso !!!. Mas mesmo que você conseguisse reduzir esse consumo, eu tenho minhas dúvidas se isso iria funcionar em WIN95, WIN98. Com certeza deve-se ao novo conceito e estruturação do proprio SO.

Também outra questão que não entendí, quando você menciona em mensagem anterior:

Estou fazendo o WAPI residente e isso envolve multi-trheading.

Qual seria essa finalidade ?. Seria para tratar a questão de bloqueio do teclado para a questão do ECF ?.

Exatamente. É o seguinte: para bloquear o teclado eu preciso instalar um hook no manipulador de eventos de teclado do Windows. Mas isso só é possível dentro da mesma tarefa. Portanto eu tenho que manter o WAPI na memória. Se ele morre depois de instalado o hook, o hook morre junto e a monitoração deixa de existir.

Maligno escreveu:Quando disse que isso envolve multi-threading, eu quis dizer que com o WAPI residente algumas tarefas poderão ser executadas ao mesmo tempo, com a criação threads. Com o WAPI transiente nada disso será possível. E hoje ele ainda é transiente. Mas mudá-lo para residente é algo que eu já previa desde o começo. Só não fiz antes porque a coisa tem que ser melhor planejada. Também com relação às funções de abstração e à possibilidade de dupla instância do programa Clipper.

Isto significaria agilidade na execução de algumas funções, isto é iriam ser executadas independentes ?. Desculpe, mas ainda não entendo o quê isso iria representar ?. Ganho de velocidade, talvez ?.

Você poderia me especificar quais foram as opções que mais se adecuaram e quais seriam as dificuldades sobre aquelas informações que nos foram passadas pelo "Ancient Dragon". Porque eu gostaria de respodner pra ele e de passo arriscar um segundo retorno.

Um clip-abraço :)Pos

E se eu usasse o WAPI.EXE diretamente na linha de comando.

Não mudaria nada.

eu tenho minhas dúvidas se isso iria funcionar em WIN95, WIN98. Com certeza deve-se ao novo conceito e estruturação do proprio SO.

Um detalhe: esse tipo de "background task" é coisa antiga no Clipper, caso não saiba. Se já conhece, me desculpe. É que tive a impressão de que não conhece.
O conceito de multi-threading, da forma como estou planejando, talvez não funcione tão bem com o Windows 98. Mas se não for possível nesta versão, o WAPI residente ainda estará disponível.

Isto significaria agilidade na execução de algumas funções, isto é iriam ser executadas independentes ?. Desculpe, mas ainda não entendo o quê isso iria representar ?. Ganho de velocidade, talvez ?.

Com multi-threading você poderia, por exemplo, imprimir, tocar música e baixar arquivos ao mesmo tempo. Ou seja, conforto e mais velocidade em algumas tarefas.

Você poderia me especificar quais foram as opções que mais se adecuaram e quais seriam as dificuldades sobre aquelas informações que nos foram passadas pelo "Ancient Dragon". Porque eu gostaria de respodner pra ele e de passo arriscar um segundo retorno.

Mas você não participa da thread do tal "Ancient Dragon". Mas em todo caso, ele dá como alternativa uma chamada ShowWindow(hWnd,SW_SHOWMAXIMIZED);, que não faz nada além de maximizar a janela DOS. Não é mudar para fullScreen, note. É maximizar.

[]'s
Maligno
http://www.buzinello.com/prg

Maligno escreveu:Mas você não participa da thread do tal "Ancient Dragon".

Será que estamos falando do mesmo caso ?. Pois já são várias a mensagens que recebí. Todas te mandei por email. Seria bom que você me confirmasse se é a mais indicada seria aquela você destacou:

Maligno escreveu:naquele link que você me passou, há uma entre as 5 alternativas que encontrei pra detectar o modo da janela. Uma delas é até interessante.

É daqui que você se referia ? ==> http://www.daniweb.com/techtalkforums/thread75750.html

Maligno escreveu:dá como alternativa uma chamada ShowWindow(hWnd,SW_SHOWMAXIMIZED);, que não faz nada além de maximizar a janela DOS. Não é mudar para fullScreen, note. É maximizar.

Disto, gostaria de fazer duas questões:

1. Isto foi extraído do link do FORUM acima indicado ?. Se não for, me diga de onde (por favor, coloque o link de onde tirou isso).

2. Esta função ShowWindow(hWnd,SW_SHOWMAXIMIZED), sabe se trabalharia em WIN98 ?. Pois se funcionar (mesmo que MAXIMIZE) a sessão que antes era como FULLSCREEN, acho que poderiamos nos conformar para aqueles casos que não funcionam na função -WINDOW2TOP do WAPI. Pelo menos quando for em WIN98, a sessão que antes estava MINIMIZADA iria "RE-ABRIR" em modo JANELADO. Ja isto seria melhor do que não dar resultado. Estamos falando da função WINDOW2TOP do WAPI em WIN98 (modo FULLSCREEN), ok ?. Sabemos que em WINXP, funciona perfeitamente. Bem até alí, não mexer, isto é, você poderia verificar se for SO WINXP pra cima restaura conforme estava, mas se for SO pra baixo, RE-ABRA a sessão SEMPRE em modo JANELADO com a implementação de ShowWindow(hWnd,SW_SHOWMAXIMIZED). Eu sou dessa opinião. Sei que soa errado, mas pelo menos a sessão WIN98 irá sempre funcionar com WIN2TOP (teoricamente).

Um clip-abraço :)Pos

Pablo César escreveu:É daqui que você se referia ? ==> http://www.daniweb.com/techtalkforums/thread75750.html

Ah, sim. Me desculpe. É que tem outra mensagem dele e eu fiz confusão.

1. Isto foi extraído do link do FORUM acima indicado ?. Se não for, me diga de onde (por favor, coloque o link de onde tirou isso).

O link é http://www.daniweb.com/techtalkforums/thread33838.html.

Sei que soa errado, mas pelo menos a sessão WIN98 irá sempre funcionar com WIN2TOP (teoricamente).

Teoricamente. Mas muito provavelmente não. Se não me falha a memória, uma aplicação minimizada não se tornaria maximizada por esta função, uma vez que há uma limitação da própria API. Mas isso tudo depende de teste para confirmar. Infelizmente o tempo está meio escasso.

[]'s
Maligno
http://www.buzinello.com/prg

Maligno escreveu:Teoricamente. Mas muito provavelmente não. Se não me falha a memória, uma aplicação minimizada não se tornaria maximizada por esta função, uma vez que há uma limitação da própria API. Mas isso tudo depende de teste para confirmar. Infelizmente o tempo está meio escasso.

Entendo. Esperarei que você faça seus testes e gostaria que você me ajudasse a compor uma pergunta pra ele, ja que até agora foi ele que teve as melhores indicações. Inclusive ele indicou o mesmo que um segundo colega Howard L tinha me indicado esta leitura: Consoles foi daqui que me surgiu aquela idéia de eu te mandei por email sobre verificação da linha 00 coluna 00 (vamos assim dizer em DOS console), claro que tavez a sua leitura seja em pixels nessa posição, mas que servirá para verificar o primeiro canto se é determinado conjunto de pixels ou é parte do Desktop ou borda de janela. Inclusive nesta ultima idéia você comentou que já tinha pensado em algo similar e que irias testar-la.

Bem fico no aguardo seus testes. Agora estou entendendo melhor as razões do multi-threading (tipo de "background task") que inclusive poderão ser útil naquela função PLAYWAVE... hehe você é uma pessoa bem persistente, né ? (acredita que esta questão do PLAYWAVE eu ví no meu sonho ?) e ví outra razão mais que agora não lembro mais. Mas pouco a pouco chegamos lá...

Um clip-abraço (vê se dorme eihnn ?) :)Pos

Pablo César escreveu:você comentou que já tinha pensado em algo similar e que irias testar-la.

Isso. A leitura do modo de vídeo vigente. Se gráfico, windowed. Se texto, fullScreen. É uma teoria a ser testada.

você é uma pessoa bem persistente, né ?

Só assim a coisa vai pra frente. ))

[]'s
Maligno
http://www.buzinello.com/prg

Olá prezado colega Maligno, como está o projeto WAPI ?. Espero que esteja avançando cada vez mais, fortalecendo a sua biblioteca/aplicativo a fim de quebrar os paradigmas que temos com o Clipper.

Parabéns pelo seu trabalho e pelo visto seu tópico foi valorizado aqui no FORUM pelo moderadores, colocando como FIXO.

Tenho mais uma sugestão/pedido/idéia... ou pent...ação como queira chamar.... hehe. Bem ja falei em mensagens anteriores aqui neste tópico sobre esta nova idéia Maligno, que claro deixo mais uma vez evidente uma das nossas necessidades e que deva ser avaliado por você a possiblidade de incrementar a seguinte idéia:

Veja os seguinte tópicos: https://pctoledo.org/forum/viewto ... bour#24721

O acima proveniente deste outro tópico: https://pctoledo.org/forum/viewtopic.php?t=5764

Essa função que é do xHarbour, muda o tipo de fonte que será impresso (seja em estilo, como tamanho). Será que teria uma função similar em BCC ? Que possa converter uma TAG dentro de um arquivo-de-impressão e re-escrevé-la em forma de comando de impressão ?. Claro que qualquer implementação neste sentido não deva fazer parte do WAPI, pois não sei se isto se aplica a API do WINDOWS. Mas que você acha Maligno ?.

Um clip-abraço e esperamos a próxima versão do WAPI. :)Pos

Pablo César escreveu:como está o projeto WAPI?

Infelizmente está parado. A parte das threads exige um pouco mais de tempo do que disponho atualmente.

Parabéns pelo seu trabalho e pelo visto seu tópico foi valorizado aqui no FORUM pelo moderadores, colocando como FIXO.

Pois é. Agradeço o Dudu por isso.

muda o tipo de fonte que será impresso (seja em estilo, como tamanho). Será que teria uma função similar em BCC?

Não. Nem poderia.

Que possa converter uma TAG dentro de um arquivo-de-impressão e re-escrevé-la em forma de comando de impressão ?. Claro que qualquer implementação neste sentido não deva fazer parte do WAPI, pois não sei se isto se aplica a API do WINDOWS. Mas que você acha Maligno ?.

Veja a coisa por um prisma diferente: qual o problema da impressão em USB? Acessar esse tipo de porta. Pelo Clipper não dá. Então fazemos uma ponte através de um programa Windows que acessa as funções da API do Windows. Até aí, fácil. Existem várias soluções pra esse problema.
Fica só um último problema: aquilo que acontece no meio do caminho, entre a geração do relatório e seu envio para o spooler. Me refiro à interpretação de certos códigos de impressão especiais (negrito, condensado, etc).
Esse problema final tanto pode ser resolvido na aplicação que encaminha o relatório para o spooler quanto na própria aplicação Clipper. Eu uso essa segunda opção. Qual a dificuldade nisso? Nenhuma. Como eu já disse antes a você, é tudo uma questão de arregaçar as mangas (tendo tempo pra isso, claro) e montar sua biblioteca de abstração desses comandos.
Eu fiz da seguinte maneira. Imprimo normalmente, inserindo algo semelhante a tags com os comandos especiais que preciso, nos trechos certos dos relatórios. Não uso @ SAY para impressão. Tenho uma função pra isso. Essa função recebe a linha a imprimir. Mas antes de iniciar a impressão seleciono qual o destino da impressão (vídeo ou impressora) e, sendo impressora, qual é. A função de impressão é então instruída a suprimir (vídeo) ou traduzir (impressora) os códigos especiais. A linha a ser impressa, salvo raras ocasiões, é enviada para um arquivo temporário. Depois de totalmente povoado, esse arquivo é direcionado ou para o vídeo ou para o spooler e, neste caso, através do WAPI.

É simples assim e funciona.

[]'s
Maligno
http://www.buzinello.com/prg