Re: Hidden CView
Thanks Tom,
The more I think about the less comfortable I get with these lines
pView->OnFilePrint();
pView->DestroyWindow();
I am afraid that DestoryWindow might delete the view object (which destroys
the BrowserControl) before the browser control had a chance to finish
printing, and I would endup with an Invalid Memory Exception on my hands.
The view approach it is.
AliR.
Now If I could customize the PrintDialog that the BrowserControl display I
would be a happy camper. But it doesn't look so go right now.
"Tom Serface" <tserface@msn.com> wrote in message
news:%23MEwzshaGHA.4416@TK2MSFTNGP04.phx.gbl...
Hi Ali,
I think putting it in the view would be the safer place to put it. Your
derived class idea makes sense because then you wouldn't have to keep
duplicating the supporting code. You can, of course, access the document
data from the view easily enough so you can do anything you want in your
printing routines.
My $.02,
Tom
"AliR" <AliR@online.nospam> wrote in message
news:4450e6fa$0$14870$a8266bb1@reader.corenews.com...
Right after I posted the message I thought about this:
I can move the OnFilePrint from CDocument dervied class to the CView
derived
class. There I can create the hidden CHtmlView in
CView::OnInitialUpdate
and destory it in CView::DestroyWindow.
This might be safer.
The reason I had the printing in the Document class was because I have
many
views that use this document, but they all print the same thing, and
what
is
being printed has nothing to do with what is being displayed in the
view.
I
can make a Common CView derived class that all the CView inherit from
that
does the printing.
But please give your input on this.
AliR.