Print Preview Behavior in an MFC app
Anthony Wieser
in the frame window or the child window in an MFC app. As a result, in
VS2005, its back in the child window, where in VC6 it was in the frame.
Unfortunately, that leaves all my toolbars active in print preview mode.
Any suggestions on how to disable the actions I don't want, or how to get
back to the VC6 behavior?
Some background reading:
Describes (some of) the history:
http://support.microsoft.com/kb/166135
A thread by David Lowndes in 2005:
http://groups.google.co.uk/group/microsoft.public.vc.mfc/browse_thread/thread/5af6d65696ff36da/62216e7efc5dd6e2?hl=en&lnk=st&q=VS2005+DoPrintPreview#62216e7efc5dd6e2
Anthony Wieser
Wieser Software Ltd
Damir Valiulin
I'm using VS2008 and also found this quite stupid. Whoever made the decision
to switch back print preview window to be embedded in Child Frame obviously
never written any real applicaion beyond Hello World. The issue you mention
with toolbars and main menu being active is exactly the reason you do want
that preview frame to cover the whole main window!
I'd also be interested in knowing some elegant solution. I quickly tried to
override some CView and CPriviewView code, but didn't explore this in detail
because it looks like you'd have to rewrite most of that stuff - not
something I have the time for currently.
Maybe we should make that developer who made this very bad design decision
write us some code with workaround. He owes us MFC developers at least that :)
Thanks,
Damir Valiulin
"Anthony Wieser" wrote:
> It seems Microsoft has been flip-flopping on whether the preview should be
> in the frame window or the child window in an MFC app. As a result, in
> VS2005, its back in the child window, where in VC6 it was in the frame.
>
> Unfortunately, that leaves all my toolbars active in print preview mode.
> Any suggestions on how to disable the actions I don't want, or how to get
> back to the VC6 behavior?
>
> Some background reading:
>
> Describes (some of) the history:
>
>
Joseph M. Newcomer
>Anthony,
>
>I'm using VS2008 and also found this quite stupid. Whoever made the decision
>to switch back print preview window to be embedded in Child Frame obviously
>never written any real applicaion beyond Hello World.
****
ANOTHER person who has detected the fundamental problem!
****
>The issue you mention
>with toolbars and main menu being active is exactly the reason you do want
>that preview frame to cover the whole main window!
>
>I'd also be interested in knowing some elegant solution. I quickly tried to
>override some CView and CPriviewView code, but didn't explore this in detail
>because it looks like you'd have to rewrite most of that stuff - not
>something I have the time for currently.
>
>Maybe we should make that developer who made this very bad design decision
>write us some code with workaround. He owes us MFC developers at least that :)
****
Just a guess at what I might try: disable the parent. Not sure if this is going to solve
it, and you might need to re-enable the print preview window, but it is something I might
look at (surprisingly, most of my work does not involve print previews, so I have very
little experience in this area)
joe
****
>
>Thanks,
>Damir Valiulin
>
>"Anthony Wieser" wrote:
>
>> It seems Microsoft has been flip-flopping on whether the preview should be
>> in the frame window or the child window in an MFC app. As a result, in
>> VS2005, its back in the child window, where in VC6 it was in the frame.
>>
>> Unfortunately, that leaves all my toolbars active in print preview mode.
>> Any suggestions on how to disable the actions I don't want, or how to get
>> back to the VC6 behavior?
>>
>> Some background reading:
>>
>> Describes (some of) the history:
>>
>>
>> A thread by David Lowndes in 2005:
>> http://groups.google.co.uk/group/microsoft.public.vc.mfc/browse_thread/thread/5af6d65696ff36da/62216e7efc5dd6e2?hl=en&lnk=st&q=VS2005+DoPrintPreview#62216e7efc5dd6e2
>>
>> Anthony Wieser
>> Wieser Software Ltd
>>
>>
Joseph M. Newcomer [MVP]
email: newc...@flounder.com
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
Anthony Wieser
"Damir Valiulin" <DamirV...@discussions.microsoft.com> wrote in message
news:388C6E23-DDB6-4271...@microsoft.com...
> Anthony,
>
> I'm using VS2008 and also found this quite stupid. Whoever made the
> decision
> to switch back print preview window to be embedded in Child Frame
> obviously
> never written any real applicaion beyond Hello World. The issue you
> mention
> with toolbars and main menu being active is exactly the reason you do want
> that preview frame to cover the whole main window!
>
> I'd also be interested in knowing some elegant solution. I quickly tried
> to
> override some CView and CPriviewView code, but didn't explore this in
> detail
> because it looks like you'd have to rewrite most of that stuff - not
> something I have the time for currently.
>
I found a partial old solution on CodeGuru, and followed up a lead from one
of the commenters
see:
<http://www.codeguru.com/cpp/w-d/doc_view/printing/comments.php/c3263/?thread=41430>
Now, what I ended up doing was in my CMDIChildDerived class I added a member
m_bPrintPreviewFrameHack.
and added this change of implmentation for is frame wnd.
BOOL CMDIChildDerived::IsFrameWnd() const
{
return m_bPrintPreviewFrameHack ? FALSE : CMDIChildWnd::IsFrameWnd();
}
Then in my view class, I handle OnFilePrintPreview, where I get my parent
(the CMDIChildDerived class), and set it's hack flag, and then call the
CView::OnFilePrintPreview implementation.
My first try was to immediately set the flag back as the commenter suggests,
but that caused an assertion failure.
So, I decided to try overriding CView::OnEndPrintPreview, and setting it
back there, after calling the default.
The net effect is that while my program is in preview mode, I claim my
window isn't a frame wnd.
Obviously this will break if for whatever reason my code were to call
GetParentFrame inside print preview, but I don't do this in my code.
Maybe this will work for you too.
Anthony Wieser
Wieser Software Ltd
>> It seems Microsoft has been flip-flopping on whether the preview should
Damir Valiulin
This looks like quite an easy fix. I am going to give it a try. The only
concern seems, like you said, IsFrameWnd which is only relevant when called
by GetParentFrame. I believe I have a few GetParentFrame calls, but I usually
put a safeguard with a IsKindOf call to verify that the frame returned is
indeed CMDIChildFrame.
Thanks,
Damir