PRINTWINDOW doesn't scale

[ckoehn]

I used the code below to test the printwindow command.  It only prints on the top left corner of the 8.5 x 11 paper.  What am I doing wrong?

Code Select Expand

ENUM prtAlignment
prt_Left=0
prt_Right=1
prt_Center=2
ENDENUM

DEF win:WINDOW

OPENWINDOW win,0,0,612,792,@NOCAPTION,0,"Print Window",&prtMain

'print something
PrintText(win,"MAIN HEADING",306,30,prt_Center)
PrintText(win,DATE$,306,50,prt_Center)

PrintText(win,"Name",30,100,prt_Left)
PrintText(win,"Address",30,120,prt_Left)
PrintText(win,"City, State ZIP",30,140,prt_Left)

PrintText(win,"1. Blah blah blah",60,180,prt_Left)
PrintText(win,"2. dddd dddd dddd",80,200,prt_Left)

PRINTWINDOW win

CLOSEWINDOW win
END

SUB prtMain
SELECT @MESSAGE
CASE @IDCREATE
CENTERWINDOW win
ENDSELECT
ENDSUB

SUB PrintText(w:WINDOW,txt:STRING,x:INT,y:INT,pos:prtAlignment)
DEF pw,ph,px,py:INT

GETTEXTSIZE w,txt,pw,ph

py=y:px=x

SELECT pos
CASE prt_Left
py-=ph/2
CASE prt_Right
px-=pw
py-=ph/2
CASE prt_Center
px-=pw/2
py-=ph/2
DEFAULT 'print at x,y

ENDSELECT
MOVE w,px,py
PRINT w,txt
ENDSUB

[REDEBOLT]

Don't you need an "OPENPRINTER" statement?

[ckoehn]

You don't need an OPENPRINTER when you use PRINTWINDOW.  PRINTWINDOW is used when you have a "GDI Printer".  I am getting a printout, but it just isn't scaling to the printer like it says in the documentation.

[LarryMc]

Suggest you read the following for possible help:

http://www.ionicwind.com/forums/index.php/topic,2988.msg24712.html#msg24712

Larry

[Johnny]

Hi,

I'm not 100% sure, but I think that in the background an "Autodraw Window" has a "drawing space" as big as the full screen is, because you could eventually stretch the window to occupy the whole screen, and that this screen size probably is the size that will be resized to fit onto the whole printer paper.

With adding a style flag @AUTOSCALE, I suppose that the background is then limited to the window size during creation of the window, at least the printout is then proportional to that window size...
(@FIXEDSIZE is also a possibility, but seems to have a disadvantage because there is then a borderline visible)

Success!

Edit: It seems that Larry answered already while I was typing my message, it took me longer because a telephone call I received...
Anyway, you can still try to open the window with the flag above.

[ckoehn]

Larry, I'm not able to go to the link you gave for some reason.  Could you help me out?

Johnny, thanks for your help.  It looks like it squashes it but it does fit from side to side.

[Copex]

Larry, I'm not able to go to the link you gave for some reason.  Could you help me out?

Johnny, thanks for your help.  It looks like it squashes it but it does fit from side to side.

copy & pasted from link larry posted...

Bill,
An autodrawn window only has a bitmap as large as your screen size that it can draw into.  If you specify @NOAUTODRAW you can draw to any virtual size in response to @IDPAINT, which is how Windows programs normally work.  The autodrawn windows are a convenience provided by Emergence, Aurora and CBasic so programmers don't need to deal with the intricacies of GDI programming. They do have their limits though, one of which is you can't draw anything larger than your system screen size when using the default window style.

So it is not a bug, it is by design.

PRINTWINDOW is also a convenience function and it makes a lot of assumptions.  For example it scales based on the horizontal DPI width of the selected printer and page size, as this is what you would want to do when you are trying to print wysiwyg from a window.  It won't be appropriate for all printing tasks though, as many have discovered.

To accomplish more advanced printing you'll need to study up a bit on device contexts, and how Windows handles the translation between logical units and device units.  It is complicated, especially if you've never done any GDI programming.  Microsoft had a good idea with device contexts, a piss poor execution, but a good idea nonetheless.  The paradigm is that a device context should isolate the programmer from the hardware so that the same code could output to a screen, plotter, printer, laser prototyping machine...whatever and reuse the same code. And it works as long as your drawing code is designed to use real world logical units. Such as feet, inches, millimeters, twips, etc.

This is known as the "mapping mode". Again something to study up on.  The default Emergence, Aurora, and CBasic windows use MM_TEXT which means 1 unit = 1 pixel in the window so when you draw a line from 0 to 99 you have a line that is 100 pixels long.  It is convenient to use this mapping mode for programs that primarily display their information on a screen, and it makes sense to newbie programmers. Unfortunately it is not convenient to use MM_TEXT mode when trying to output to a printer.  Think about "dots per inch" for a moment.  A CRT or LCD screen commonly uses 96 DPI, meaning there are 96 pixels per inch of screen space.  Printers on the other hand commonly use 600, 1200 or 2400 DPI.  If you were to try and use the same output code that draws to the screen in MM_TEXT mode on a printer you would end up with a little tiny image in the upper left corner of the paper.

Which is why I included PRINTWINDOW in the first place, just as a convenience to do the scaling and copy the internal window bitmap to a printer device context.

Printing, in reality, is application specific, and there is no way I can write a "one size fits all" function to handle everyones needs.  I really should do a tutorial on mapping modes though, and how you can use them to produce the same output on different devices.  For example you could use MM_LOENGLISH where each "unit" is .01 inch, so if you were to draw a line from 0 to 99 it would be 1 inch on the screen or the printer.  The piss poor execution by Microsoft comes into play here though, when using a mapping mode other than MM_TEXT the Y axis is reversed so that positive Y values go up the window instead of down.  Also the origin ends up in the middle of your window so you have to change it if you want an origin (0,0) to be in the upper left corner of the windows client area.

In any event this describes the various mapping modes:

http://msdn.microsoft.com/en-us/library/ms533160(VS.85).aspx

Paul.