Entendo seu desabafo Rubem, mas aí fico na dúvida: quando eu preciso fazer
impressões matriciais, quase sempre faço como me acostumei a fazer no Clipper
(nem sei se era a maneira correta, mas era como eu entendia...), ou seja,
imaginar que cada linha que eu quisesse escrever teria no máximo 80 colunas por
40 linhas e jogar tudo num arquivo TXT que depois era enviado para a impressora.
Mas porém, todavia, entretanto, não é necessário (pelo menos ao meu ver) um
componente de terceiros e sequer um editor visual. Basta (para minha
necessidade) usar uma variável do tipo TStrings ou até um TStringList e vou
gerando os parágrafos do meu relatório com base na largura do texto que é
inserido. E para mandar para a impressora, bastaria um Write da vida, fazendo
uma ejeção de página a cada 40 linhas.
Alguma automação como definir a ordem das colunas é bem vinda, mas nada além
disso, pois visualmente a impressão matricial é "pobre". O valor é agregado a
informação e não ao layout do relatório.
Não sei se nesse caso em específico seria mais fácil já ter algo pronto...
Sendo que a composição desse tipo de relatório é bastante simples.
Atte,
Ricardo.
_________________________________________________________________
"Vamos ajudar o Grupo e o Yahoo! Apague o conteúdo irrelevante!"
--- Em qua, 25/2/09, Rubem Nascimento da Rocha <djpardalro...@hotmail.com>
escreveu:
POR QUÊ O DELPHI NÃO VÊM COM TUDO DE QUE PRECISO?
por Rubem Nascimento da Rocha
____________ _________ _________ _________ _________ _
Eram os idos de 1994, quando desde 92 comecei a desenvolver soluções em
Clipper. Era uma linguagem fantástica, e apesar de ter mudado de foco, ainda é.
Basta pesquisar que se encontra muita coisa legal voltada para Clipper e xBase.
Mas daí, quando estava iniciando minhas incursões em desenvolvimento para
Windows com Visual FoxPro 3, já se ouvia os buchichos e os alardes sobre o
Delphi. Quando descobri o Delphi por acaso, apenas pela curiosidade de saber
como era um código feito nessa ferramenta, foi amor à primeira vista. Isto pq
sempre fui fã de carteirinha da linguagem Pascal, e até a existência da
linguagem C++, sempre considerei a linguagem C anti-didática e difícil de se
entender por ter, a meu ver, uma sintaxe mais mnemônica do que próxima de uma
linguagem formal. Mas aí, ao longo do tempo que mais e mais descobria coisas
maravilhosas com a ferramenta, como orientação a objetos, começaram a aparecer
novos desafios na rotina
cotidiana de programação. E uma delas era saída de dados para impressoras
matriciais. Falando direto ao ponto pra quem não gosta de textos muito
coloquiais, impressão de relatórios em impressoras matriciais.
Muito bati cabeça para procurar ser performático e prático como na época em que
desenvolvia relatórios em Clipper. Mas no mundo Windows, tudo é gráfico,
incluindo as saídas impressas. E as alternativas que surgiam não me atendiam
neste requisito. Muitos me falaram q o ReportBuilder permitia saída em
matricial na boa, mas ainda não vi isso na prática. QuickReport e
CrystalReports então, nem se fala! Uns e outros que desenvolvem em .NET dizem
que o CrystalReports 'güenta' o tranco. O povo do Java diz que
iReport/JasperRepor ts tb resolve tranquilo. Mas o fato é que na época, as
alternativas que procurei utilizar não me permitiam ter a mesma praticidade e
performance que tinha no Clipper, pois todas eram orientadas à saídas gráficas.
Quem nunca tentou imprimir um relatório do QuickReport em matricial e se
deparou com aquela lerdeza da cabeça de impressão 'desenhando' as letras no
papel? Pois é, aí está o motivo! Impressões em
Windows são desenhadas, pois são gráficas!
Aí o povo começou a tacar pau no Delphi! Claro, qualidade inerente do ser
humano é falar mal do que não se conhece ou do que não se procura saber a causa
de tal comportamento! Muitos que bateram cabeça em imprimir em matricial
começaram a se perguntar indignados, porém sem a mínima noção do teor da
pergunta: 'Pô, pq o Delphi num vêm com um componente pra imprimir em
matricial?' Depois de muito pesquisar na Internet sobre maneiras de imprimir em
matricial de forma rápida, havia me deparado com um componente chamado RDPrint,
feito por uma empresa brasileira. Eu cheguei a fazer uso dele em uma aplicação
de retaguarda comercial. Como diriam os mineiros, 'O trem era bão memo, sô!'
Claro, não tinha um designer gráfico de relatórios como o QuickReport, mas em
compensação o povo que vinha do Clipper adorou o bichinho! Depois de muito usar
este componente, uma curiosidade apareceu e uma 'ficha havia caído'.
A curiosidade era saber como o RDPrint era capaz de tal façanha. Fuçando e
fuçando, descobri q ele apenas fazia uso de chamadas à API do Windows que
permitiam escrever dados na impressora de maneira crua ('RAW'), sem passar pelo
gerenciador de impressão. O fato depois foi comprovado depois que vi o código
fonte de alguns outros componentes free feitos também por brasileiros, como o
RSPrint e o VDOPrint.
A 'ficha havia caído' depois de uma profunda avaliação de meu cotidiano de
trabalho juntamente com o Delphi. E nessa minha avaliação, levando em conta
meus mais de 10 anos trabalhando com Delphi, é óbvio e fato mais que consumado
que a produtividade nesta ferramenta é fantástica, mas os artefatos que ele
fornece inicialmente ao desenvolvedor têm o intuito de atenderem, a nível
mundial, a gregos e troianos (por assim dizer). Ou seja, se houvessem mais e
mais desenvolvedores ao redor do mundo que tivessem necessidade de impressão
matricial, com certeza a Borland/CodeGear/ Embarcadero/ Seja-Lá-Qual-
Será-o-Próximo- Nome/etc teria embutido no produto, desde as suas primeiras
versões, um componente para gerar impressão em matricial. Portanto, é
necessário que seja entendido e compreendido o fato de que o Delphi, por ser um
produto utilizado a nível mundial, não têm a pretensão de realmente ter
praticamente tudo o que se precisa de uma
ferramenta de desenvolvimento no que diz respeito de nossas rotinas cotidianas
de programação. Por dois motivos: (1)Não são todos os desenvolvedores ao redor
do mundo que têm a mesma necessidade cotidiana, como impressão em impressoras
matriciais; (2)Por conta do motivo #1, assim como acontece com a Microsoft, a
Borland deixou o Delphi com um conjunto básico de componentes visuais com o
intuito de que outros desenvolvedores e/ou empresas de software pudessem
desenvolver soluções que atendessem necessidades cotidianas específicas, tais
como as suites(a.k.a. , coleções) de componetes consagradas na comunidade
Delphi InfoPower, DevExpress e ReportBuilder e componentes de terceiros criados
por desenvolvedores brasileiros que tiveram enfoque de resolver problemas
cotidianos de desenvolvedores brazucas, tais como o RDPrint, RSPrint e VDOPrint.
Poderia incluir um terceiro motivo, que seria o fato da equipe de
desenvolvimento do Delphi não ver como viável desenvolver customizações do
produto específicas para determinados nichos de mercado, pois um trabalho neste
sentido consumiria muito tempo para se pesquisar, no meio da comunidade de
desenvolvedores, as necessidades cotidianas de cada desenvolvedor em cada país,
e tal tempo seria custoso ($$$) e poderia encarecer o produto final. Podem ser
especulações ou hipóteses. Julguem como quiser, mas a experiência em
desenvolvimento, e a forma como as empresas que fornecem ferramentas de
desenvolvimento de software lidam com o mercado a nível mundial trabalham me
levam a crer nessas linhas de pensamento.
Um abraço a todos.
Rubem Rocha
Manaus, AM
Veja quais são os assuntos do momento no Yahoo! +Buscados
http://br.maisbuscados.yahoo.com
[As partes desta mensagem que não continham texto foram removidas]
