ActiveX Printing Problem

[Ben Schwartz]

I developed an ActiveX control using Visual Basic 6.0. This control is

intended to be able to load a specified graphic from a file, store it, and

display it. I developed the control in order to be able to have a reliable,

lightweight mechanism of embedding a graphic in a document. (Side point if

you are wondering why the necessity to have a new component to perfrom this

function: When creating a new OLE object from a graphics file, OLE will use

whatever server is available on the system to handle the file. A given user

might not have any server on his machine to handle a given format, or the

server he has might be grotesquely heavyweight or otherwise inappropriate for

embedding, such as Microsoft Photo Editor, etc. It's important for me to have

one lightweight component that will do the job well for many formats.)


My control is called PictureServerControl. In the app I'm writing, when a

user wants to insert a graphic, my app embeds a PictureServerControl in the

document. Then it invokes a method of the PictureServerControl and passes it

the filename of the desired graphic. The control loads the graphic and

displays it. The picture then persists along with the control, making the

picture a permanent part of the document.


The control seems to work flawlessly until one tries to do a print or print

preview. Some containers, such as Microsoft Word, will produce correct

results. But many containers, WordPad for example, will produce incorrect

results.


Let's discuss what happens when you try to print. If you embed a

PictureServerControl in a WordPad document and print the document, the

printed graphic appears way too small. It seems that each inch of the graphic

gets shrunk to about 100 pixels. That is: Let's say the graphic is 1 inch by

1 inch. On the printer, it prints as about 100 pixels by 100 pixels. That's

no good, since a printer pixel is far smaller than 1/100 inch. I performed an

experiment and changed the printer resolution so that the printer only prints

half as many pixels horizontally (vertical resolution unchanged). I printed

again, and lo and behold, the graphic now printed twice as wide as before and

its height was unchanged (making it totally distorted). The too-small graphic

tends to be placed in the upper-right hand corner of what was supposed to be

its bounding rectangle (in fact, it's a bit cut off at the top); in my

container app, it's the same but in the upper left-hand corner. (I wonder

whether this assumed 1 inch = abt. 100 pixels conversion that's taking place

has to do with an assumed screen resolution?)


The behavior varies from container to container. As I mentioned, in MS Word,

everything works great. On the other extreme, in MS Outlook (in a mail item),

the control entirely fails to print (perhaps it is being drawn in the wrong

place, and it's outside the clipping region.) A blank space of the correct

size is left where the graphic should be. The behavior in my own container

software I'm writing is quite similar to that of WordPad (which makes sense

since they're both MFC apps.)


As I understand, ActiveX components generate metafiles which are used by

containers for printing. If you insert a PictureServerControl into

Microsoft's ActiveX Control Test Container and request a metafile, it looks

just great. This seems to indicate that my control is producing its metafile

correctly. Why that doesn't turn into correct output on the printer is a

mystery to me.


As for print preview, the graphic generally seems to be correctly sized but

incorrectly positioned, or does not appear at all. In WordPad it previews

correctly but only at the maximum zoom (100%) - otherwise the graphic does

not appear at all (possibly being rendered somewhere off the paper). It's

difficult to make diagnoses from print preview since print preview mechanisms

are so complicated.


Here are a few more funny things I've noticed. Perhaps one of them will lend

a clue.


1. Even when registered, my control does not appear in the Insert Object

dialog box produced by most apps. (That's just fine with me since I intend

the control to be specific to my app, but perhaps it means something. There's

some category not being implemented...? See next paragraph.


2. Microsoft's OLE/COM Object Viewer reports that my control is not in the

Embeddable Objects category. (Am I not implementing some necessary

interfaces? Which ones? I don't seem to be missing any of those interfaces

which I see are common to all Embeddable Objects. I have not been able to

find any complete technical description of what makes something an Embeddable

Object.)


3. I originally intended to have my control honor the ambient BackColor

property. For some reason, this resulted in an VB error being raised when my

app created an instance of the control in a document; the error was "Client

Site not Available", which seems to mean that my control was unable to access

ambient properties. (I didn't try to access to ambient properties too soon,

that's not the problem.) Interestingly, my control was able to access ambient

properties just fine in the ActiveX Control Test Container. I resolved this

problem by not accessing the ambient properties and assuming that the correct

back color is white, a rather good assumption in most cases I'd be dealing

with. (This would be good to resolve also, if possible.)


4. A cosmetic problem: When resizing PictureServerControl in the ActiveX

Control Test Container, if you resize it to be smaller than before, the

original large image is not erased. Those parts of the original large image

which fall outside the new rectange are left over - they only go away when

you force a redraw of the window (for example, by moving it offscreen and

then moving it back.) This does not happen in other container software, such

as my own (and looks like it could be a bug in the Test Container.)


If anybody has any suggestions please e-mail me at bschwartz@geneer.com


Thanks.