Lazarus
Programming => Packages and Libraries => RichMemo => Topic started by: rick2691 on October 02, 2016, 04:31:58 pm
-
It appears that EM_FORMATRANGE might have been changed at about halfway through our working with the function.
It now formats with an extra line. By appearance it looks as if it is proper, but a printer will not fit that last line on the page.
It also seems that word wrapping has slightly changed. It used to do exactly as WordPad would do with lines and wrapping, and now both are different.
To be sure I went back to my first code, and there is a PDF on the PrintViewer thread. The oldest version does the same as newest one, and it is not what is posted on the thread.
Rick
-
Here is the older version, as per the thread post.
That didn't work... You'll have to go look it up.
-
I assume you are comparing it with the image in this post (http://forum.lazarus.freepascal.org/index.php/topic,33885.msg221396.html#msg221396).
It seems to me that you changed the format. Check the attached image.
-
Yes, it looks as though you are correct... I must have changed the RETURN attribute at some point.
But why does that change the EM_FORMATRANGE result so that it incorrectly shows that the format will fit on a page?
When printing it sends the last line to the next page.
Rick
-
I would have done it by deleting the RETURN space and doing a new RETURN from the lesser font. Something I sometimes do to make things look better.
Does printing insist that a RETURN is from the higher font with its attributes?
Rick
-
I edited through with the RETURN's to see if it corrected anything, and it did not. I still may have changed the font size to get the extra line. But I sent the file to WordPad, and it showed a Preview that pushed the last line to the next page. EM_FORMATRANGE is still retaining that line on page 1. The following is the WordPad preview.
-
The following also a printing by RichMemo to a PDF printer. It shows that the last line belongs on the next page.
-
I'm not sure if I totally understand your problem but my experience with RICHED20.dll (and other RichEdit versions) is that they are very sensitive to the assigned hdc and hdcTarget.
I've used it a lot in Delphi and always had a difference in wrapping of lines on screen and on a real printer (or PDF-printer). I finally settled to filling the hdc and hdcTarget with the default printer handle even when using a screen-view.
-
Thanks. I'll give that a try.
-
rvk... you are a good man (or person). That made it work.