memo no Rave

438 views
Skip to first unread message

Felipe Dal Pizzol

unread,
Dec 7, 2009, 8:45:02 AM12/7/09
to dug...@googlegroups.com
Buenas indiada!

Estou numa peleia das grandes aqui.

Fiz um relatório no rave e o funcionamento permanece
correto até o momento em que incluo um componente
memo, seja ele database ou não.

Nesse momento, ao gerar o relatório, entra em loop e, se
estiver para gerar em memória, logo dá out of memory,
se estiver em disco, vai gerando...

Mais detalhes que posso passar é que a base é Access,
com ADO. Tentei criar uma banda somente para o memo
em questão e o mesmo com databand, mas é sempre o
mesmo resultado.

Alguma dica?

Grato,

--
Felipe Dornelles Dal'Pizzol

Felipe Dal Pizzol

unread,
Dec 8, 2009, 6:41:29 AM12/8/09
to dug...@googlegroups.com
Sem sugestões?

2009/12/7 Felipe Dal Pizzol <fdalp...@gmail.com>

Christian Bobsin

unread,
Dec 8, 2009, 11:06:21 AM12/8/09
to dug...@googlegroups.com
Bem não é uma sugestão mas um comentário.

Ontem eu estava montando um relatório para imprimir um grafico e acidentalmente deixei o metafile maior que a  a databand delimitada no relatório. qdo testei a geração... Ao invés de gerar uma página como devia começou e gerar páginas, páginas e mais páginas! 

Mas foi eu percerber isso e corrigir que não aconteceu mais.

Não seria este o teu problema o componente no report mal dimensionado gerando este erro?

Att,
Christian Regina Bobsin

2009/12/8 Felipe Dal Pizzol <fdalp...@gmail.com>



--
-----------------------------------
Christian Regina Bobsin

Felipe Dal Pizzol

unread,
Dec 9, 2009, 7:09:50 AM12/9/09
to dug...@googlegroups.com
bom dia, Christian!

até poderia ser, mas como o memo tem tamanho variável, e tem a propriedade ExpandParent, teoricamente não deveria existir problemas.

Cheguei a utilizar somente um Memo (não DB), com texto fixo e tamanho e limites bem definidos.... teoricamente era só imprimir, mas o erro persistiu.

Agora, depois de tanto mexer, fazer o que ja havia feito (configurações, componentes, dimensões), remover e incluir componente, e várias tentativas, ele está funcionando... não sei por quanto tempo, pois não houve uma configuração que corrigisse esse problema.

Veremos o que acontecerá!

2009/12/8 Christian Bobsin <christi...@gmail.com>

Felipe Dal Pizzol

unread,
Dec 17, 2009, 12:54:43 PM12/17/09
to dug...@googlegroups.com

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

sup...@nevrona.com

 

 

 

 

That’s all p..p…pessoal!!!

Festaaaaa!

 


Boas festas!

 

Dal’Pizzol.




2009/12/9 Felipe Dal Pizzol <fdalp...@gmail.com>
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



--
Felipe Dornelles Dal'Pizzol
Reply all
Reply to author
Forward
0 new messages