Toolkit Pro - Saving contents of windows 'underneath' MenuBar

Print Page | Close Window

Saving contents of windows 'underneath' MenuBar

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=6354
Printed Date: 28 April 2024 at 5:29pm
Software Version: Web Wiz Forums 12.04 - http://www.webwizforums.com

Topic: Saving contents of windows 'underneath' MenuBar

Posted By: asparagusx
Subject: Saving contents of windows 'underneath' MenuBar
Date Posted: 08 February 2007 at 9:28am

Hallo

I am implementing the XTP library into a CAD (computer aided design) system and so far so good!

However, I have come across an issue when displaying a 'context menu' e.g. user right clicks, the menu displays (I am using CXTPCommandBars::TrackPopupMenu(pSubMenu, TPM_LEFTALIGN | TPM_RIGHTBUTTON, point.x, point.y, pMain,0,0,pMain->pCommandBars);
)

The menu displays correctly but when the menu is hidden, our application receives a large number of 'redraw requests', which then forces a refresh of the area previously under the contect menu.

Question - is it possible to 'save' the contents of the underlying window(s), prior to displaying the context and then restoring it afterwards (e.g. CS_SAVEBITS | CS_BYTEALIGNWINDOW) to minimise calls to what could be very complex graphics.

Anton Heymann

Replies:

Posted By: asparagusx
Date Posted: 09 February 2007 at 7:51am

Anybody any ideas about this. It has actually turned out to be a serious issue as performance is of absolute importance in this application.

Thank you in advance.

Anton Heymann

Posted By: Oleg
Date Posted: 09 February 2007 at 9:03am

Hi,

1 What version of Toolkit do you have? Actually we use CS_SAVEBITS and I tried to show popup in our sample and it doesn't generate WM_PAINT messages at all.

2. if performance of drawing is so critical, I very recommend you start cashing drawing, like we do in our Report and Ribbon - it gave us great perfomance.

Something like:

if ( (IsChanged() || m_bmpCache.GetSafeHandle() == 0))
{
CDC memDC;
memDC.CreateCompatibleDC(&dc);

m_bmpCache.DeleteObject();
m_bmpCache.CreateCompatibleBitmap(&dc, rc.Width(), rc.Height());

CBitmap* pOldBitmap = memDC.SelectObject(&m_bmpCache);

OnDraw(&memDC);

dc.BitBlt(0, 0, rc.right, rc.bottom, &memDC, 0, 0, SRCCOPY);

  memDC.SelectObject(pOldBitmap);
}
else
{
  CXTPCompatibleDC memDC(&dc, &m_bmpCache);
  dc.BitBlt(0, 0, rc.right, rc.bottom, &memDC, 0, 0, SRCCOPY);
}

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

Posted By: asparagusx
Date Posted: 09 February 2007 at 9:21am

Oleg

Thanks for the reply. I have been looking at this in detail and I can see (from the source - we use 10.4.2), that CS_SAVEBITS is only used when creating Popup's and Shadow windows. The code for CXTPControlBars (or derived classes) does not appear to use this at all. I also tried setting

bUseSystemSaveBitsStyle = TRUE, but it appears that is the default in any case and made no difference. When I use TrackPopupmenu, I certainly get redraw requests sent to the application. I used BCMenu before (CodeGuru) and it certainly was not a problem there. I am obviously optimising redraws as much as possible and already use MemDC where possible. I do believe that the solution is for Codejock to add CS_SAVEBITS to additional controls, such as CXTBControlBars and derivitaves. When I 'drag' toolbars accross our application (when repositioning them) the resulting loss of performance is substantial and end-users will not be able to use the system.

Thanks

Anton

Posted By: asparagusx
Date Posted: 09 February 2007 at 9:44am

Oleg

To add to the problem, it appears that when the popup menu is hidden (e.g. it is removed from the window), the client area underneath the popup (the area where our drawing is being displayed in) is totally invalidated e.g. InvalidateRect(NULL), rather than InvalidateRect(the screen area of the popup). I am making assumptions here re the drawing code, but my application is certainly receiving (via test to ::RectVisible) that the entire client are has been invalidated.

Anton