Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Bug in Print When of detail band footer
Message
General information
Forum:
Visual FoxPro
Category:
Reports & Report designer
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Miscellaneous
Thread ID:
01151756
Message ID:
01152339
Views:
24
Thanks for the reply, Cathy. In the interest of time, I had already created an external, logical memory variable that I use in the Print When and it worked fine (although a bit kludgy.)

I'm really surprised that a pretty obvious bug like this exists. But, the inability to easily suppress the band header and footer if no records exists seems to point to the fact that they didn't put a lot of thought into the band headers and footers.

Let me know if you figure out anything about the root problem.

>I don't have time to research the possible bug right now .. but for a workaround try this: Create a report variable that counts the records printed in the band. Use a PrintWhen of that variable <> 0 in the detail footer.
>
>
>>Hi All,
>>
>>I have found a bug in the VFP 9 report writer. I am trying to conditionally print the footer for a detail band by using the Print When for the objects in the detail band footer. But, no matter what condition (based on the report data) that I use in the Print When for the objects (including the "recommended" method of using "!eof({targetalias})"), the footers are *always* suppressed.
>>
>>After some testing, I discovered that there is some very squirrelly behavior going on in the detail footer processing. For example, I changed the Print When for one of the objects to call a test function that would echo to the screen the value passed to the function (!eof('targetalias') in this case.) When run, it was revealed that the function was called 23 times and that the value was True 19 times and False 4 times (4th, 7th and 21st occurences) in every case no matter how many detail records in the target alias?!
>>
>>Has anyone seen this behavior before? Is there a better work-around than creating a variable BEFORE the report is run to use in the Print When condition?
Later...
/< /-/
Previous
Reply
Map
View

Click here to load this message in the networking platform