[reportlab-users] Flowing onto second column

[Robin Becker]

Jim Steil wrote:

> Robin Becker wrote:

>> Jim Steil wrote:

>>> Tim Roberts wrote:

>>>> Jim Steil wrote:

>>>>>

>>>>> Is there an easy way to get data to flow to a second column the way 

>>>>> you can get it to flow to multiple pages with Platypus?

>>>>

>>>> Sure.  You just create multiple frames, one for each column, and add 

>>>> the collection of frames when you create the PageTemplate.

>>>>

>>>> Here's a web page that shows an example:

>>>>    http://www.hoboes.com/Mimsy/?ART=558

>>>>

>>> Ok, I'm trying to get my report working per the instructions at the 

>>> link above.  However, I've changed it a bit because instead of having 

>>> paragraphs display in my columns, I have tables that I want to snake 

>>> around the columns.  So, where this doc refers to paragraphs in the 

>>> 'items' list, I'm appending tables.  But, when I get to the 

>>> document.build(posts) statement, I get the following dump:

>>>

>>> Traceback (most recent call last):

>>>  File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 187, in 

>>> <module>

>>>    priceSheets(filename)

>>>  File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 178, in 

>>> priceSheets

>>>    go(doc, c)

>>>  File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 167, in go

>>>    doc.build(allData)

>>>  File 

>>> "c:\python25\lib\site-packages\reportlab\platypus\doctemplate.py", 

>>> line 749, in build

>>>    tr.srcFile,

>>> AttributeError: Field instance has no attribute 'srcFile'

>>>

>>> I'm stumped as to where I should look for the problem.  Can anyone 

>>> give me any clues?

>> .......

>> well tr is obtained because the erroneous flowable was given some sort 

>> of _traceInfo. That should be an object with the following attributes

>>

>> srcFile,startLineNo,endLineNo,endLinePos

>>

>> if it doesn't have those attributes then an error will result. I don't 

>> think there's any way that _traceInfo can be non None unless it's 

>> being set somewhere deliberately. Just create a tracing class and use 

>> that instead of a simple string or whatever. I suppose we could 

>> consider allowing _traceInfo to be a simple string of your choosing 

>> and using that rather than a structured object. I have to confess I 

>> know little (or perhaps have forgotten) about this code. I suspect in 

>> the modern world we'd just make _traceInfo something with a __str__ 

>> method (or a str).

> So, are you implying that I should be looking into the doctemplate.py 

> and find a better solution to the reportlab code?  I don't think I have 

> the depth of knowledge necessary to take that on.  Or, are you saying 

> that I'm giving it a bad flowable that is causing the problem?  If so, 

> how could I identify that?

........
no I'm saying I don't know how you managed to end up with this tr._traceInfo 
problem. I just checked most of our code base and the only refs to _traceInfo 
are in doctemplate.py and flowables.py. Every flowable is supposed to descend 
from Flowable which has an initial setting of _traceInfo to None. The code in 
doctemplate is then only supposd to try and refer to x._traceInfo if 1) 
hasattr(x,'_traceInfo') is True and 2) x._traceInfo is non-zero. If that's the 
case then we attempt to pull those attributes of the _traceInfo object and 
incorporate them into the current traceback. That's so we get a more detailed 
error message when a particular flowable is putting this _traceInfo onto itself 
with some meaninful info (like which file it came from and where etc etc).

So is there anywhere in your code where _traceInfo is mentioned?
-- 
Robin Becker