Continued Report Problems in 8099

[Sarah Mitchell]

I will be testing 8425 this weekend. I didn't see anything specific in the release notes about printing issues, but I have hope.

There are LOTS of fixes for Reports in 8425 despite the release notes.

[iRadiate]

I have just installed 8245 this afternoon and I haven't noticed any issues with reports, everything looks great so far!

[Pizzadude]

I installed the development version and did a quick test. I have objects not rendering on reports, and font issues. I will post more details tomorrow. Good to see Sarah Mitchell on this thread!

[Pizzadude]

Here are two printouts of the same report. The report contains 5 RTF objects, populated with data from a MySQL table. 2 of the objects are not rendered in 8425.
The report is produced using Javascript Action Open a Report, Label or Letter layout.
I have not tried to troubleshoot it yet. I will try to build a test case to demonstrate it.

This is rendered in build 7902:

FaxCoverCorrect.png

This is rendered in build 8425:
FaxCoverWrong.png

[gregincolumbus]

Im curious....what happens to the report if you remove the email address. Maybe the rendering issue on 8425 has something to do with the link?

Nothing appears after that in your second attachment

[Sarah Mitchell]

Here are two printouts of the same report. The report contains 5 RTF objects, populated with data from a MySQL table. 2 of the objects are not rendered in 8425.
The report is produced using Javascript Action Open a Report, Label or Letter layout.
I have not tried to troubleshoot it yet. I will try to build a test case to demonstrate it.

This is rendered in build 7902:

FaxCoverCorrect.png

This is rendered in build 8425:
FaxCoverWrong.png

See https://documentation.alphasoftware....oject%20report

If you have a reproducible test case on the current release (or even better, the current nightly), then we can investigate.

[Pizzadude]

I will attempt to make a reproducible case and send a bug report.

[Pizzadude]

Update...

I mistakenly said in my earlier post that the objects on the report that don't render are RTFs. They are actually HTML objects.

This is how I am populating the HTML object:

I have a UX, with a TextArea control set as an HTML editor.

The TextArea value is saved in a MySQL blob field.

The data source in the report retrieves the value in the blob field.

The problem seems to be that the report will not always render the html, depending on exactly what the html is.

For example: <div>Hello World</div> renders just fine.

But <div><br></div><div>Hello World</div> will not render.

Alpha's HTML editor, in my experience, has a habit of adding code here and there, and adding code repetitively.

While <div><br></div> is not very good html code, v.7902 renders it and v.8425 does not. And it will display correctly in the TextArea HTML control, in both 7902 and 8425.

There is other html code that prevents it from rendering on the report. this is just a simple example that can be reproduced.

[Pizzadude]

Here is a stand-alone report that reproduces this. Open it in the report editor, then print preview.

Can anyone tell why this works in v.7902 but not in v.8425?

TestReport.zip

[Tim Sutherland]

Update...

I mistakenly said in my earlier post that the objects on the report that don't render are RTFs. They are actually HTML objects.

This is how I am populating the HTML object:

I have a UX, with a TextArea control set as an HTML editor.

The TextArea value is saved in a MySQL blob field.

The data source in the report retrieves the value in the blob field.

The problem seems to be that the report will not always render the html, depending on exactly what the html is.

For example: <div>Hello World</div> renders just fine.

But <div><br></div><div>Hello World</div> will not render.

Alpha's HTML editor, in my experience, has a habit of adding code here and there, and adding code repetitively.

While <div><br></div> is not very good html code, v.7902 renders it and v.8425 does not. And it will display correctly in the TextArea HTML control, in both 7902 and 8425.

There is other html code that prevents it from rendering on the report. this is just a simple example that can be reproduced.

Have you seen this in the updated release notes?

Perhaps it may help with your issue.



Reports - HTML Content - Default Style Sheet - pdf.css - If a PDF report contains an HTML control, you can now specify a default style sheet for the HTML content by adding a file called pdf.css to the web project folder.
The reason for this feature is that HTML content in reports is rendered using a 3rd party control called HTMLLayout. Recently Alpha Anywhere began including a new version of the HTMLLayout control and this has resulted in some reports with HTML content rendering differently than they did in the past. because the default style sheet used by the new HTMLLayout control differs from the one used in older versions of Alpha Anywhere.

For example, assume you added a pdf.css file to your web project with this content:

body {

background: orange;
margin: 0px;
padding: 0px;
}

The HTML content in your report would be rendered with an orange background.



In addition, the pdf.css file can set certain properties that control how a reports is rendered as a PDF file.
The pdf.css file can have this in it:
html { print-settings: no-padding collapse-row-height; }

no-padding - controls horizontal padding between words. Use this property if your report has lines that have too much spacing between objects on a horizontal line. If no-padding is set then you may end up with objects that overlap.
collapse-row-height - use this property if a table in a PDF report is less tightly compacted than in the report preview.

[iRadiate]

Here is a stand-alone report that reproduces this. Open it in the report editor, then print preview.

Can anyone tell why this works in v.7902 but not in v.8425?

[ATTACH]n937791[/ATTACH]

I am getting the same result in build 8245

1.jpg

2.jpg

Looks like a good test case!

[Pizzadude]

Reports - HTML Content - Default Style Sheet - pdf.css

I don't remember seeing this when I read the release notes a day after the release date. Was this added later?

Anyway, I tried implementing this and testing in 8425. It does not specify any required content for the pdf.css file, only that it must exist.

I tried it with the content suggested in the help: html { print-settings: no-padding collapse-row-height; }, This made no difference.

I tried it with:
body {

background: orange;
margin: 0px;
padding: 0px;
}
This had no effect. The background was not orange.

Looks like a good test case!

I am sending a bug report.

[peteconway]

Build 8099 - works fine. See image.


I don't use anything beyond that to many issues. - like I commented 2 moths ago here.. what a mess.

[Pizzadude]

Selwyn's response: yes, it is a bug, but luckily there is a trivial work around. just set the growable property to ON

xx.png

Apparently the Growable property is a recent addition. I don't see it in 7902.
But checking Growable, while fixing the problem with rendering the object, is messing with the layout of some of my reports, sending some text onto an extra page. This may be a layout problem I can fix. Still testing...
I have not been using 8099 due to this and other bugs.

[peteconway]

All I can say is what I know - it worked on 8099 on my server. View the image) - Any how it's a bug - so you know the answer, maybe wait for the fix before chasing down what's messing up in the layout still.
in https://download.alphasoftware.com/R...o_present.html - growable appears once.

Layout Table Reports - Property Grid - Certain properties that do not support dynamic features were listed in the Property Grid, suggesting that you could define a dynamic value for the property. The Property Grid no longer allows you to define dynamic property values for these properties. For example, "height" and "growable" cannot be changed at run-time.