[reportlab-users] Flowing onto second column
robin at reportlab.com
Thu Feb 14 11:30:18 EST 2008
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:
>>> 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
>>> File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 178, in
>>> go(doc, c)
>>> File "C:\PyWork\Motion\motion\utility\priceSheet.py", line 167, in go
>>> line 749, in build
>>> 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
>> 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?
More information about the reportlab-users