Meu desafio contra o Rave: “Retroceder nunca, render-se jamais”
Buenas, nas andanças pelos caminhos encontrados na minha vida de desenvolvedor Delphi, sempre tive aquela impressão, e até uma certeza, de nunca ter encontrado “O Sensei” ou o “Mestre Yoda” na arte dos relatórios.
Em diversas ocasiões encontrei pessoas com um vasto conhecimento, mas, toda vez que encontrava a pessoa que considerei ser “O Escolhido”, ou mestre nas artes do relatório, notava que era um maluco encarnado que peleou muito pra resolver um problema que surgiu no relatório que necessitava e que dois dias depois já tinha esquecido a solução encontrada...
Buenas, isso foi tanto no QuickReport quanto no Rave, que considero ser muito usados, até por virem junto com o Delphi.
Eis que na empresa que estou prestando serviço atualmente, cheguei com vários objetivos, mas a missão que pegou mais, foi a de fazer relatórios no Rave... “Putz... Rave... nunca vi!!”... Com isso, ressurgiu esse maluco que tem por lema “No Retreat, No Surrender”, ou como diria um ditado do meu pago, “Dou um boi pra não entrar em uma briga, mas uma boiada pra não sair”.
Cenário: Imprimir dados de uma base do Access. Entre os dados, campos texto (Memo e DataMemo), com tamanho variável.
A Pendenga: Ao mandar imprimir ocorreram alguns problemas:
Pendenga 1: Geração interminável de páginas.
Pendenga 2: O MSAccess armazena dois bytes para o campo memo. Ao mandar imprimir, surgia texto como este: “A o m a n d a r i m p r i m i r ....”
Características:
A) Dados tabela mestre (primeiro nível)
B) Dados tabela detalhe (segundo nível)
C) Dados tabela detalhe-detalhe (terceiro nível)
D) Resumo de características do relatório (volta primeiro nível)
E) Texto tamanho variável 1
F) Outro Texto tamanho variável (Database – tantas quantas forem ocorrências)
G) Texto tamanho variável 2
Soluções encontradas:
1) Quando se carrega um campo memo do Access em um ADOTable ou Query, ele vem com o tipo TWideMemoField e a propriedade BlobType = ftWideMemo. Para resolver o problema da aparição dos caracteres malucos apresentados anteriormente, foi feito a troca da propriedade BlobType de ftWideMemo para ftMemo, conforme sugerido aqui: http://qc.embarcadero.com/wc/qcmain.aspx?d=22937 .
Ate já havia tentado trocar o ftWideMemo para ftWideString, mas não rolou. Deu erro... Entretanto, com o ftMemo, show de bola! Rolou! Matou a pau!
2) E o erro de geração infinita de páginas? Bom, pra isso eu reduzi bandas e memos para altura de aproximadamente uma linha e construí o relatório desta forma:
Reconstruindo:
A) Dados tabela mestre (primeiro nível) [DataBand]
B) Dados tabela detalhe (segundo nível) [DataBand] Controller = A)
C) Dados tabela detalhe-detalhe (terceiro nível) [DataBand] Controller = A)
D) Resumo de características do relatório [DataBand] Controller = A)
E) Texto tamanho variável 1 [Band com DataMemo] Controller = D)
F) Outro Texto tamanho variável (Database) [DataBand com DataMemo] Controller = D)
G) Texto tamanho variável 2 [Band com DataMemo] Controller = D)
Como não obtive muitas respostas até conseguir chegar a essa solução, repasso o que encontre.
Após achar essa solução e escrever este documento, recebi a informação de um maluco da França, que recebeu a seguinte resposta do suporte Nevrona:
we have had a problem with pages being created without stopping in certain conditions when using DataMemo(s) in a DataBand. Usually, there is no problem with a report with a single DataBand with a single DataMemo. But, there can be a page status "communication" issue between the DataBand component and the each DataMemo component when doing multiple memos over a page break. So if you have multiple DataBands and multiple DataMemos -- then you have increased your chance for having endless pages being created.
If that is what you are talking about then you may have hit one of the corners
/ limits of the visual designer. The developer is very aware of that problem
and the fix is to completely rewrite the DataBand logic. Unfortunately, there
has been absolutely no time for him to do this. There is one possible
solution....
Anytime the
complexity of your report becomes very difficult / impossible to accomplish
with the visual designer, then we recommend that you consider looking at doing
that report with the code base side of Rave. The code base
side has literally hundreds of methods / properties available to accomplish extremely
complex reports. If you have not looked at the code side, then I would suggest
looking at the tutorial on code base (link can be found out on
our web page) along with many "tips and tricks". We do provide a code
base demo (with full source) on some installs. Check your Rave installation folder
and see if you have a sub-folder called "Code" or "Code2".
--
Tech Support
Nevrona Designs
That’s all p..p…pessoal!!!
Festaaaaa!
Boas festas!
Dal’Pizzol.
2009/12/8 Christian Bobsin <christi...@gmail.com>
--~--~---------~--~----~------------~-------~--~----~
Você recebeu esta mensagem porque está inscrito no "DUG-RS -
Delphi Users Group Rio Grande do Sul" em Grupos do Google.
Acesse o nosso BLOG em http://www.dug-rs.org e contribua com a comunidade Delphi do Rio Grande do Sul
Para postar neste grupo, envie um e-mail para dug...@googlegroups.com
Para cancelar a sua inscrição neste grupo, envie um e-mail para
dug-rs-un...@googlegroups.com
Para ver mais opções, visite este grupo em
http://groups.google.com.br/group/dug-rs?hl=pt-BR
-~----------~----~----~----~------~----~------~--~---
--
Felipe Dornelles Dal'Pizzol