You can fix this problem by moving the DirectX SDK path in the Include files list to the last position in the list. Although Visual Studio 2010 beta 1 does not allow you to edit the Include files list directly in the Options dialog, you can edit the list by modifying one of the following files depending on operating system you are using:

C:\Users\%username%\AppData\Local\Microsoft\VisualStudio\10.0\Microsoft.Cpp.Win32.User.Props
      C:\Users\%username%\AppData\Local\Microsoft\VisualStudio\10.0\Microsoft.Cpp.X64.User.Props

with C:\Users\%username%\ being your user folder on Windows Vista.

Find the IncludePath XML node in the file, which contains a list of entries delimited with a semi-colon. The entry representing the DirectX SDK typically looks like

C:\Program Files (x86)\Microsoft DirectX SDK (November 2008)\Include

C:\Program Files\Microsoft DirectX SDK (November 2008)\Include

In most cases, DirectX SDK is the first in list. Just move it to the last position. This should let Visual Studio 2010 beta 1 compile your project successfully.

You can use the MFC's CWnd::SetFont() method, which works for any control in Prof-UIS.

Another option is to change the font for all controls in the application by using the global property g_PaintManager->m_FontNormal. You can find an example of how to do this in the FunnyBar sample that comes with Prof-UIS.

You should implement the CExtPmBridge interface in one or more of your classes:

// In .h file:
class CSomeYourClass
      : public C_BASE_OF_CSomeYourClass
      , public CExtPmBridge
{
public:
      DECLARE_CExtPmBridge_MEMBERS( CSomeYourClass );
      CSomeYourClass();
      ~CSomeYourClass();
      virtual void PmBridge_OnPaintManagerChanged(
            CExtPaintManager * pGlobalPM
            );
      . . .
};

// In .cpp file:
IMPLEMENT_CExtPmBridge_MEMBERS( CSomeYourClass );

CSomeYourClass::CSomeYourClass()
{
      PmBridge_Install(); // Subscribe
}

CSomeYourClass::~CSomeYourClass()
{
      PmBridge_Uninstall(); // Unsubscribe
}

void CSomeYourClass::PmBridge_OnPaintManagerChanged(
      CExtPaintManager * pGlobalPM
      )
{
      CExtPmBridge::PmBridge_OnPaintManagerChanged(
            pGlobalPM
            );
      ::AfxMessageBox( _T("The Paint Manager has changed!") );
}

If C_BASE_OF_CSomeYourClass is a Prof-UIS class, it may be already derived from CExtPmBridge and you only need to override the CExtPmBridge::PmBridge_OnPaintManagerChanged() virtual method in this case.

If you store the UI state in the registry, you can use the following code to load the paint manager's state:

CWinApp * pApp = ::AfxGetApp();
ASSERT( pApp != NULL );
ASSERT( pApp->m_pszRegistryKey != NULL );
ASSERT( pApp->m_pszRegistryKey[0] != _T('\0') );
ASSERT( pApp->m_pszProfileName != NULL );
ASSERT( pApp->m_pszProfileName[0] != _T('\0') );

if( ! g_PaintManager.PaintManagerStateLoad(
      pApp->m_pszRegistryKey,
      pApp->m_pszProfileName,
      pApp->m_pszProfileName
      )
   )
   g_PaintManager.InstallPaintManager(
      RUNTIME_CLASS(CExtPaintManagerOffice2007_R2_LunaBlue)
   );

To initialize the application faster, load the paint manager's state before any window in your application is created. You can put the above code, for instance, into a constructor of the main frame or dialog window.

The code below saves the paint manager's state to the registry:

CWinApp * pApp = ::AfxGetApp();
ASSERT( pApp != NULL );
ASSERT( pApp->m_pszRegistryKey != NULL );
ASSERT( pApp->m_pszRegistryKey[0] != _T('\0') );
ASSERT( pApp->m_pszProfileName != NULL );
ASSERT( pApp->m_pszProfileName[0] != _T('\0') );

VERIFY(
   g_PaintManager.PaintManagerStateSave(
      pApp->m_pszRegistryKey,
      pApp->m_pszProfileName,
      pApp->m_pszProfileName
      )
   );

You can also serialize the paint manager's state to a CArchive using the PaintManagerStateSerialize() method.

There is no API for working with PNG images in the main library itself (ProfUISDLL and ProfUISLIB projects in the Prof-UIS workspace). However, there is another library that comes with Prof-UIS and provides this functionality: ProfSkin (ProfSkinDLL and ProfSkinLIB projects). Please note there are two third-party libraries that are used in ProfSkin, LibPng and Zlib, which are free for any use.

You can load a PNG from a file or a resource using the CExtSkinBitmap class implemented in ProfSkin. After the image is loaded, you can use it wherever you want in your application. For example, you can use it for initializing any of the following properties of a CExtCmdIcon object:

CExtBitmap m_bmpNormal;
CExtBitmap m_bmpDisabled;
CExtBitmap m_bmpHover;
CExtBitmap m_bmpPressed;

1) Include ProfSkin.h in your StdAfx.h file:

...
#include <Prof-UIS.h>
#include <../ProfSkin/ProfSkin>
...

2) Compile both LibPNG and ZLib.

3) Compile ProfSkin.

4) Here is sample code for loading two PNG images:

CExtSkinBitmap _bmpTmp;

// Load PNG from resources:
LPCTSTR strPngImageResourceID = MAKEINTRESOURCE( ID_YOUR_PNG_RESOURCE_IMAGE );
LPCTSTR strPngResourceSection = _T("PNG");
HINSTANCE hInst = ::AfxFindResourceHandle( strPngImageResourceID, strPngResourceSection );
ASSERT( hInst );
HRSRC hRsrc = ::FindResourceHandle( hInst, strPngImageResourceID, strPngResourceSection );
ASSERT( hRsrc );
VERIFY( _bmpTmp.LoadPNG_Resource( hInst, hRsrc ) );
pSomeRibbonNode1->m_iconBig = _bmpTmp;

// Load PNG from file:
VERIFY( _bmpTmp.LoadPNG_File( _T("C:\Folder\picture.png") ) );
pSomeRibbonNode2->m_iconBig = _bmpTmp;

This feature is supported in all Prof-UIS paint manages and demonstrated in the TabbedBars sample. Here is how you could implement a custom background in your window:

1) Turn on the feature at start up or after changing the paint manager:

g_PaintManager->m_bCustomBackgroundInheritanceEnabled = true;

After that every window will be receiving the CExtPaintManager::g_nMsgPaintInheritedBackground registered Windows message and this allows you to paint any custom background in the message handler.

2) Add the following message map entry to your window class:

ON_REGISTERED_MESSAGE(
    CExtPaintManager::g_nMsgPaintInheritedBackground,
    OnMsgPaintInheritedBackground
    )

3) Implement the CYourWindow::OnMsgPaintInheritedBackground() handler method. You can use the CChildView::OnMsgPaintInheritedBackground() method from the TabbedBars sample as a ready-to-use solution. This method paints the background of tab pages in the CChildView class, which is an extended version of the One Note tab page container

Download a sample project that demonstrates consistent background painting.

First of all, add the anchor support for CFormView with the CExtWA template as it is described in the FAQ How to make CFormView to be look and act like CExtResizableDialog? After that, you can anchor your controls with an AddAnchor() method provided by CExtWA.

Please note that when the CFormView::OnInitialUpdate() method is called, the current size of the form view is already changed (i.e., it is not equal to the original size of the loaded dialog template resource). So, if you try to anchor your controls in the OnInitialUpdate() method, you may get unexpected results. That is why we recommend you set up anchors when the frame window, which is the parent of the form view, is created:

int CMainFrame::OnCreate(LPCREATESTRUCT lpCreateStruct)
{
    if (CFrameWnd::OnCreate(lpCreateStruct) == -1)
        return -1;
 
    // create a view to occupy the client area of the frame
    m_pWndView = new CChildFormView;
    if (!m_pWndView->Create(
            NULL, 
            NULL, 
            AFX_WS_DEFAULT_VIEW, 
            CRect(0, 0, 0, 0), 
            this, 
            AFX_IDW_PANE_FIRST, 
            NULL
            )
        )
    {
        TRACE0("Failed to create view window\n");
        return -1;
    }
 
    ....
 
    if( !m_wndMenuBar.Create(
            NULL,            this,
            ID_VIEW_MENUBAR
            )
        )
    {
        TRACE0("Failed to create menubar\n");
        return -1;      // failed to create
    }
 
    m_pWndView->AddAnchor( IDC_YOUR_CONTROL, __RDA_LT, __RDA_RT );
 
...

There are two types of DLLs which are using MFC:

• MFC regular DLL
• MFC extension DLL

The major difference is that you can use regular DLLs in non-MFC projects (C, C++, Pascal, Visual Basic, and so on) whereas extension DLLs can be used only in MFC executable or DLL projects. Here are some details about using Prof-UIS in DLL projects.

Regular DLL

This type of DLL can be used in any projects regardless of whether they are MFC or non-MFC DLL/EXE. Any MFC-based Active X project is an example of the most often used kind of MFC regular DLL project. For example, a Frame Features Active X control presented on our site is also a regular DLL.

Any regular DLL has its own global CWinApp-derived object usually named theApp. The regular DLL uses its own copy of the MFC host and for all the exported methods the current module state should be explicitly set with MFC's AFX_MANAGE_STATE macro at the beginning of each exported method.

To use Prof-UIS in your regular DLL project, include Prof-UIS.h in the StdAfx.h file, define the __PROF_UIS_FOR_REGULAR_DLL preprocessor symbol in the project settings, and invoke the following code in the InitInstance() virtual method of the CWinApp-derived class:

CExt_ProfUIS_ModuleState::InitExtension(
    AfxGetStaticModuleState()
    );

If you use the ProfAuto library, additionally include the ../ProfAuto/Prof-UIS-AutomationPack.h file and invoke the code below:

 CExt_ProfAuto_ModuleState::InitExtension(
    AfxGetStaticModuleState()
    ); 

If you use the ProfSkin library, additionally include the ./ProfSkin/ProfSkin.h file and invoke the code below:

CExt_ProfSkin_ModuleState::InitExtension(
    AfxGetStaticModuleState()
    ); 

If you have both a Prof-UIS based EXE and use a regular DLL, they have their own independent hosts of Prof-UIS and MFC. That means these two modules use independent copies of the Prof-UIS paint manager and you need to toggle between supported themes synchronously in both modules.

Extension DLL

This type of DLL can be used only in MFC-based EXE projects, in MFC extension projects, and in MFC regular DLL projects. Prof-UIS supports both a set of extension DLL configurations and a set if regular DLL extension configurations. The later is marked with the RDE label. Such a division cannot be avoided because a DLL is initialized differently in EXE projects and in regular DLL projects.

The extension DLL does not have its own global CWinApp-derived object and uses the same MFC and Prof-UIS hosts as in the module in which it is loaded. So, you do not need to care about Prof-UIS theme synchronization issues for this type of DLL at all.

To use Prof-UIS in your MFC/Prof-UIS-based EXE project or in your extension DLL project, it is enough just to include Prof-UIS.h in the StdAfx.h file. Do not forget to include ../ProfAuto/Prof-UIS-AutomationPack.h if you use the ProfAuto library and ../ProfSkin/ProfSkin.h for ProfSkin.

The simplest way is to change settings of your project to Use MFC in a Static Library. This will make Prof-UIS be statically linked as well. Do not forget to build the appropriate configuration of the profuislib project first, e.g. Static MBCS Debug if your application uses the Multi-Byte Character Set.

To use Prof-UIS as a static library linked to your project that is dynamically linked with MFC, do the following:

• Build the appropriate configuration of the profuislib library project, e.g. Static MBCS Debug with MFC DLL.
• Modify the settings of your project by adding __STATPROFUIS_WITH_DLLMFC__ to the Preprocessor Definitions field in the C/C++ and Resources categories.
• Compile your project.

As you know, static libraries typically do not contain any resources inside. That means, if you use Prof-UIS as a static library, you cannot use any resource-dependent features like customization, color selection and icon editor dialogs, localization, and etc. But starting from Prof-UIS 2.52, we introduced an easy way to enable the resource-dependent features in static builds. The workaround is based on including Prof-UIS resources directly to your project. To make all the resource-dependent features available in your project that is statically linked with Prof-UIS, do the following:

• Rebuild the appropriate Win32 Static … configuration of the profuislib project, e.g Static MBCS Debug.
• Add these lines to your *.rc2 file just after Add manually edited resources here...

  ///////////////////////////////////////////////////////////////////////////// 
  // Add manually edited resources here... 
  #if ( !(defined _AFXDLL && !defined __STATPROFUIS_WITH_DLLMFC__) ) 
          #include <Resources/Resource.rc> 
  #endif 
  /////////////////////////////////////////////////////////////////////////////

//header
class CChildFormView : public CExtWA < CExtWS < CExtAFV < CFormView >  > >
{
...
...
...



//implementation
IMPLEMENT_DYNCREATE(CChildFormView, CFormView)
 
CChildFormView::CChildFormView()
    : CExtWA < CExtWS < CExtAFV < CFormView >  > > ( CChildFormView::IDD, ((CWnd *)NULL) )
...
...
...

To apply an XP visual style to the common controls in your application, use ComCtl32.dll version 6 or later. Unlike earlier versions of ComCtl32.dll, version 6 is not redistributable. The only way you can use version 6 of the dynamic-link library (DLL) is to use an operating system that contains it. Windows XP ships with both version 5 and version 6. ComCtl32.dll version 6 contains both the user controls and the common controls. By default, applications use the user controls defined in User32.dll and the common controls defined in ComCtl32.dll version 5.

So, to use visual styles in your application, you must add an application manifest that indicates that ComCtl32.dll version 6 should be used if it is available. Below is an XML content of the manifest file:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?> 
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
   <assemblyIdentity 
      processorArchitecture="x86" 
      version="5.1.0.0"
      type="win32"
      name="APPLICATION_NAME"
      />
   <description>APPLICATION_DESCRIPTION</description>
   <dependency>
      <dependentAssembly>
         <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            publicKeyToken="6595b64144ccf1df"
            language="*"
            processorArchitecture="x86"
            />
      </dependentAssembly>
   </dependency>
</assembly>

Replace APPLICATION_NAME with the name of your application and APPLICATION_DESCRIPTION with a brief description.

1. Place the XML manifest file in the same directory as your application's executable file. The manifest should be named YourApp.exe.manifest, which is a name of the application executable file.
2. Embed the manifest into the application resources.
   • First, add the following line to the resource.h file. Just copy and paste the following:

        #define IDR_MANIFEST 1

     Don't forget to save the file.
   • In the Resource View window, right click the resource tree and choose Import..., select the manifest file you have just created and press OK to close the dialog.
   • When the Custom Resource Type dialog opens, enter 24 and press OK.
   • Rename the newly imported resource under 24 to IDR_MANIFEST.
   • Rebuild the application.

The CExtPaintManagerStudio2005 paint manager supports two GUI themes similar to those implemented in Microsoft Visual Studio Beta 1 and Beta 2. These GUI themes have tangible differences with regard to docking markers, control bar captions, tabs and other subtleties. You can switch between these graphical interfaces by setting __ES2005_BETA1 or __ES2005_BETA2 to the g_PaintManager->m_eStyle2005 property like as follows:

g_PaintManager->m_eStyle2005 = 
   CExtPaintManagerStudio2005::__ES2005_BETA1;
// or
g_PaintManager->m_eStyle2005 = 
   CExtPaintManagerStudio2005::__ES2005_BETA2;

Please do not forget the application's main window:
- frame-based applications

RecalcLayout();
RedrawWindow(
    NULL,
    NULL,
    RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE | RDW_ERASENOW
        | RDW_FRAME | RDW_ALLCHILDREN
    );
CExtControlBar::stat_RedrawFloatingFrames( this );
CExtControlBar::stat_RecalcBarMetrics( this );

- dialog-based applications

CWnd::RepositionBars(0,0xFFFF,0);
RedrawWindow( 
    NULL, 
    NULL,
    RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE | RDW_ERASENOW
        | RDW_FRAME | RDW_ALLCHILDREN
    );
UpdateDialogControls( this, FALSE );

This can be done by excluding some features that may be redundant in your project. Prof-UIS is designed in a way that the base source code is the same for Prof-UIS Freeware and for the full version. In the Prof-UIS.h file you can find constants that begin with __EXT_MFC_NO_ (e.g., __EXT_MFC_NO_GRIDBASEWND ). In Prof-UIS Freeware the preprocessor directives that declare these constants are not commented and thus their corresponding features are excluded from the free version. In a similar way, you can exclude some features from the full commercial version and hence make the library of a smaller size. For instance, if you do not need the grid control and your application is not customizable, just uncomment the lines below:

//#define __EXT_MFC_NO_GRIDBASEWND
//#define __EXT_MFC_NO_GRIDWND
//#define __EXT_MFC_NO_CUSTOMIZE

#define __EXT_MFC_NO_GRIDBASEWND
#define __EXT_MFC_NO_GRIDWND
#define __EXT_MFC_NO_CUSTOMIZE

You can also reduce the library size by excluding Office2007 paint managers. To do this, just comment the following line in the Prof-UIS\Include\Resources\resource.rc resource file:

#include "Res2007\\Res2007.rc"

#define __EXT_MFC_NO_RESOURCES_xxxxxxx

NOTE: To take these changes into effect, do not forget to recompile the library.