Re: Data Report: Do it the hard way :-)

"Ivar" <Ivar.ekstromer000@xxxxxxxxxxxx> wrote in message
news:J%Fzi.20437$mo.11400@xxxxxxxxxxxxxxxxxxxxxxx

>Do it the hard way, Ivar. You might even enjoy it ;-)

I probably would ;-) but i'm still trying to do some other stuff the
hard way so I thought I would try to do this the easy hard way.
Found this:
http://www.Planet-Source-Code.com/vb/scripts/ShowCode.asp?txtCodeId=37488&lngWId=1
Looks interesting, but has limitations and drawbacks (don't wanna
write picture files to hard drive) so not to sure about it.

I've never seen that code before so I don't yet know for certain exactly how it works but I've just downloaded it now for a quick look and it seems to be using the more or less standard simple print preview technique of passing a DC to a main printing routine and using more or less the same code to set up the font and graphic settings of the DC and then sending text and images to it. That method does allow you to fairly easily dump the same (or rather similar) output to a printer or to a screen DC or a picture box and to fairly easily scale at output for preview purposes. However, such a technique only really works well for images and line drawings. It has serious problems with text, mostly because of the very different resolutions of the output devices. You can see the effects of this problem straight away if you download the code from the link you posted and run the PrintPreviewDemo_BMP example and click the Print Preview Instructions button and perform both a Preview and a Print to the printer. The results depend on your system and on the printer you are using but you will probably see that on the very first page at least some of the individual lines of the small block of text end on a different word in the preview than they do on the actual printed page and that the block itself possibly takes up a different total number of lines (for example on my machine there are six lines in the print preview but only five lines on the printer). The same sort of thing happens on other blocks of text on other pages in the document.

These incorrect wrap problems are due to the different resolutions of the two devices (the screen and the printer) and they almost always occur when you use standard text block printing techniques on two different devices simply by providing a different DC to the printing function. The problem occurs for a very specific reason to do with the "whole pixel" value that Windows likes to have for its font point sizes and also for the width of each of the individual font characters. To do it properly so that the preview looks exactly the same as the actual printout you need to print your stuff in a different way that takes this stuff into account. There are of course ways of solving the problem (I can think of about three different methods offhand) but unfortunately I haven't actually got any "pre written" examples for you. These days I don't get a lot of time to spend writing code and most of the examples I post are either quick half hour jobs or stuff that I have written some time ago. I'll certainly be able to help you with the problem though (and so will other people here) if you decide to write your own stuff, but I can't really help you with modifications to the code you have downloaded because to be frank it is going about the job in completely the wrong way.

Mike




.