[reportlab-users] Flowing onto second column
jim at qlf.com
Thu Feb 14 11:39:25 EST 2008
Robin Becker wrote:
> 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
>>> 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?
No, there is not. I'm making some changes to the code now. I think I
may have not been wrapping things in a list exactly as the sample had
done. I'm verifying/fixing that now and will be back once I find the
result. Thanks for helping out on this.
More information about the reportlab-users