Toolkit Pro - Print preview in 12.0.0 not working properly

Print Page | Close Window

Print preview in 12.0.0 not working properly

Printed From: Codejock Forums
Category: Codejock Products
Forum Name: Toolkit Pro
Forum Description: Topics Related to Codejock Toolkit Pro
URL: http://forum.codejock.com/forum_posts.asp?TID=11076
Printed Date: 12 July 2025 at 8:11pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Print preview in 12.0.0 not working properly

Posted By: Harm Bakker
Subject: Print preview in 12.0.0 not working properly
Date Posted: 17 June 2008 at 9:22am

Hello,

we have recently upgraded to XT toolkit pro, version 12.0.0. The PrintPreview functionality does not seem to work properly anymore, and we haven't been able to figure out what we are doing wrong:

1. Print preview in previous versions took over all of the client space; in the new version, print preview acts in an MDI child view, which is fine except that the rest of all application functions (menus, toolbars) stay visible, and should either keep on working or be disabled. Is there an option to turn this MDI print preview behavior off? Or to make the

2. In a print preview window we have now two overlapping toolbars. One toolbar is created by CView::DoPrintPreview with code:

if ( pFrame && pView->m_pToolBar->Create(pFrame, ATL_MAKEINTRESOURCE(nIDResource),CBRS_TOP, AFX_IDW_PREVIEW_BAR) )

and a second one is created in CXTPPreviewView::OnCreate with code:

if (!m_wndToolBar.CreateToolBar( WS_CHILD | WS_VISIBLE | CBRS_TOP | CBRS_GRIPPER | CBRS_TOOLTIPS, m_pToolBar) ||

!m_wndToolBar.LoadToolBar( XTP_IDR_PREVIEW_TOOLBAR ) )

The result is that there are two overlapping toolbars with similar functions/buttons, which is not what we had/want.

3. When resizing the application window, the preview window does not redraw itself correctly, and forgets to redraw most parts of the window.

Did anyone else have these problems too? It seems that we are doing some things wrong here, but after stepping through code for a couple of days now, the problem has not become clear yet. What can we do to make this work again as expected?

Replies:

Posted By: Oleg
Date Posted: 17 June 2008 at 10:07am

Hi,

1. Think with Toolkit you also upgraded MFC version. it's the thing of .NET - you can see it with new project without our Controls.

2, 3. Can't reproduce it with our PrintPreview sample. Can you check it ?

-------------
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS

Posted By: Harm Bakker
Date Posted: 20 June 2008 at 10:34am

In the XT PrintPreview sample I also see only one toolbar. So I have stepped through the sample code and noticed that the sample uses the resource id XTP_IDD_PREVIEW_DIALOGBAR to load / create the toolbar, whereas in our code we have XTP_IDD_PREVIEW_TOOLBAR. Changing that one to XTP_IDD_PREVIEW_DIALOGBAR solves the double overlapping toolbars! One down, two to go...

Two problems remain: (1) the view does not redraw itself correctly when sizing it (it leaves all kind of parts of preview pages behind), and (2) when the print button is pressed, the preview is closed, but the print dialog does not appear.

Posted By: Oleg
Date Posted: 20 June 2008 at 1:40pm

Hi,

1. Do you see same with our sample?

2. Do you see same with our sample?

-------------
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS

Posted By: Harm Bakker
Date Posted: 23 June 2008 at 12:01pm

Both problems only appear in our application, the sample seems to be working fine. Yet, we have simply upgraded to version 12.0.0, and did not change anything in our code, so something must have changed somewhere for this behaviour to appear. In order to investigate the redrawing problem further I have traced the windows messages with Spy++, and saw that in the PrintPreview sample (and also in our previous application version in which everything worked fine) in response to a window resize, the app receives the following messages:

<00181> 00061F52 S WM_WINDOWPOSCHANGING lpwp:0012E9D0
<00182> 00061F52 R WM_WINDOWPOSCHANGING
<00183> 00061F52 S WM_NCCALCSIZE fCalcValidRects:True lpncsp:0012E9A4
<00184> 00061F52 R WM_NCCALCSIZE fuValidRect:0000 lpncsp:0012E9A4
<00185> 00061F52 S WM_WINDOWPOSCHANGED lpwp:0012E9D0
<00186> 00061F52 S WM_SIZE fwSizeType:SIZE_RESTORED nWidth:572 nHeight:328
<00187> 00061F52 R WM_SIZE
<00188> 00061F52 R WM_WINDOWPOSCHANGED
<00189> 00061F52 S WM_PAINT hdc:00000000
<00190> 00061F52 S WM_NCPAINT hrgn:00000001
<00191> 00061F52 R WM_NCPAINT
<00192> 00061F52 S WM_ERASEBKGND hdc:B4011AE2
<00193> 00061F52 R WM_ERASEBKGND fErased:True
<00194> 00061F52 R WM_PAINT

In our current application however, we receive the following messages:

<00014> 0006095A S WM_WINDOWPOSCHANGING lpwp:0012DFFC
<00015> 0006095A R WM_WINDOWPOSCHANGING
<00016> 0006095A S WM_NCCALCSIZE fCalcValidRects:True lpncsp:0012DFD0
<00017> 0006095A R WM_NCCALCSIZE fuValidRect:0000 lpncsp:0012DFD0
<00018> 0006095A S WM_WINDOWPOSCHANGED lpwp:0012DFFC
<00019> 0006095A S WM_SIZE fwSizeType:SIZE_RESTORED nWidth:536 nHeight:302
<00020> 0006095A R WM_SIZE
<00021> 0006095A R WM_WINDOWPOSCHANGED
<00022> 0006095A S WM_PAINT hdc:00000000
<00023> 0006095A S WM_NCPAINT hrgn:6E0430EC
<00024> 0006095A R WM_NCPAINT
<00025> 0006095A R WM_PAINT

The difference is that we do not receive WM_ERASEBKGND messages anymore, which probably is the cause for our window only being redrawn partly, leaving all kinds of rubbish behind. What could cause this omission of WM_ERASEBKGND ???

Kind regards,

Harm

Posted By: Harm Bakker
Date Posted: 24 June 2008 at 12:05pm

In response to the print preview not redrawing itself correctly:

Our fix for Print Preview view not correctly drawing itself: when resizing a view in print preview, the view is not entirely redrawn correctly. Cause of this seems to be that the containing CFrameWnd does not have the CS_VREDRAW or CS_HREDRAW styles for its window class. (In the XT Toolkit sample, the frame has these styles, so there the problem does not occur.) Adding an extra Invalidate() in CXTPPreviewView::OnWindowPosChanged will cause the view to be redrawn in its entirety.

So, OnWindowPosChanged now looks like this (Oleg, can you confirm that this is ok?)

void CXTPPreviewView::OnWindowPosChanged(WINDOWPOS FAR* lpwndpos)

{

CPreviewView::OnWindowPosChanged(lpwndpos);

// If the toolbar is a window...

if ( ::IsWindow( m_wndToolBar.m_hWnd ) )

{

// Get a pointer to the parent frame.

CFrameWnd* pFrameWnd = m_pToolBar->GetDockingFrame( );

ASSERT_VALID( pFrameWnd );

// Get the size of the client area for the docking frame.

CRect r;

pFrameWnd->GetClientRect( &r );

// Calculate the actual size of the toolbar.

CSize size = m_wndToolBar.CalcDockingLayout(r.Width), /*LM_HIDEWRAP| */ LM_HORZDOCK | LM_HORZ | LM_COMMIT);

size.cx = r.Width( );

// Set the height of the dialog bar equal to the

// toolbar's height.

m_pToolBar->m_sizeDefault.cy = size.cy;

// Reposition the toolbar.

m_wndToolBar.MoveWindow( 0, 0, size.cx, size.cy );

m_wndToolBar.Invalidate(FALSE);

}

// BiZZdesign fix for Print Preview view not correctly drawing itself: when resizing

// a view in print preview, the view is not entirely redrawn correctly. Cause of this

// seems to be that the containing CFrameWnd does not have the CS_VREDRAW or CS_HREDRAW

// styles for its window class. (In the XT Toolkit sample, the frame has these styles, so there

// the problem does not occur.) Adding an extra Invalidate() here will cause the view to

// be redrawn in its entirety.

Invalidate();

}

The second problem, the Print command not being activated from within the print preview: this was solved by routing the command correctly through our derived CMDIChildFrame.

Kind

Posted By: Oleg
Date Posted: 24 June 2008 at 3:04pm

Thanks. Invalidate added.

-------------
Oleg, Support Team
CODEJOCK SOFTWARE SOLUTIONS