Forum

Dear Support,

I need to prevent the user from changing the height of CExtPropertyGridCtrl rows.

Thanks,
Ron.

The property grid control contains two tree grid windows initialized by default: categorized property tree and sorted property tree. Both cannot be resized by default. We can guess you have custom trees in the property grid. If it is the case, could we take a look at the code that initializes these tree grids?

My mistake - I meant width.

Hi.
I have a problem again. My MDI application crashes when closed. Unhandled exception is received in ExtHook.cpp line 216.

Here is the stack:

    DpdfDesignerd.exe!CArray<CExtHookSink *,CExtHookSink *>::GetSize() Line 279 + 0x11 bytes    C++
>    DpdfDesignerd.exe!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=130, unsigned int & wParam=0, long & lParam=0) Line 216 + 0xb bytes    C++
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00230d00, unsigned int nMessage=130, unsigned int wParam=0, long lParam=0) Line 271 + 0x14 bytes    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_DispatchClientMessage@20() + 0x4d bytes    
    user32.dll!___fnNCDESTROY@4() + 0x26 bytes    
    ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13 bytes    
    user32.dll!_NtUserDestroyWindow@4() + 0xc bytes    
    DpdfDesignerd.exe!DpdfDesigner::CMainFrame::DestroyWindow() Line 621    C++
    DpdfDesignerd.exe!CFrameWnd::OnClose() Line 849    C++
    DpdfDesignerd.exe!DpdfDesigner::CMainFrame::OnClose() Line 721    C++
    DpdfDesignerd.exe!CWnd::OnWndMsg(unsigned int message=16, unsigned int wParam=0, long lParam=0, long * pResult=0x02a1f040) Line 2028    C++
    DpdfDesignerd.exe!CWnd::WindowProc(unsigned int message=16, unsigned int wParam=0, long lParam=0) Line 1741 + 0x20 bytes    C++
    DpdfDesignerd.exe!AfxCallWndProc(CWnd * pWnd=0x04256b68, HWND__ * hWnd=0x00120cfc, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 240 + 0x1c bytes    C++
    DpdfDesignerd.exe!AfxWndProc(HWND__ * hWnd=0x00120cfc, unsigned int nMsg=16, unsigned int wParam=0, long lParam=0) Line 389    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_CallWindowProcAorW@24() + 0x51 bytes    
    user32.dll!_CallWindowProcW@20() + 0x1b bytes    
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=16, unsigned int & wParam=0, long & lParam=0) Line 213 + 0x20 bytes    C++
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00120cfc, unsigned int nMessage=16, unsigned int wParam=0, long lParam=0) Line 271 + 0x14 bytes    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_DispatchClientMessage@20() + 0x4d bytes    
    user32.dll!___fnDWORD@4() + 0x24 bytes    
    ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13 bytes    
    user32.dll!_NtUserMessageCall@28() + 0xc bytes    
    user32.dll!_DefFrameProcWorker@24() + 0x8f bytes    
    user32.dll!_DefFrameProcW@20() + 0x1b bytes    
    DpdfDesignerd.exe!CMDIFrameWnd::DefWindowProcW(unsigned int nMsg=274, unsigned int wParam=61536, long lParam=460024) Line 188    C++
    DpdfDesignerd.exe!CWnd::Default() Line 274    C++
    DpdfDesignerd.exe!CWnd::OnSysCommand(unsigned int __formal=61536, unsigned int __formal=61536) Line 460 + 0xf bytes    C++
    DpdfDesignerd.exe!CFrameWnd::OnSysCommand(unsigned int nID=61536, long lParam=460024) Line 1046    C++
    DpdfDesignerd.exe!CWnd::OnWndMsg(unsigned int message=274, unsigned int wParam=61536, long lParam=460024, long * pResult=0x02a1f664) Line 2056    C++
    DpdfDesignerd.exe!CWnd::WindowProc(unsigned int message=274, unsigned int wParam=61536, long lParam=460024) Line 1741 + 0x20 bytes    C++
    DpdfDesignerd.exe!AfxCallWndProc(CWnd * pWnd=0x04256b68, HWND__ * hWnd=0x00120cfc, unsigned int nMsg=274, unsigned int wParam=61536, long lParam=460024) Line 240 + 0x1c bytes    C++
    DpdfDesignerd.exe!AfxWndProc(HWND__ * hWnd=0x00120cfc, unsigned int nMsg=274, unsigned int wParam=61536, long lParam=460024) Line 389    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_CallWindowProcAorW@24() + 0x51 bytes    
    user32.dll!_CallWindowProcW@20() + 0x1b bytes    
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=274, unsigned int & wParam=61536, long & lParam=460024) Line 213 + 0x20 bytes    C++
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00120cfc, unsigned int nMessage=274, unsigned int wParam=61536, long lParam=460024) Line 271 + 0x14 bytes    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_DispatchClientMessage@20() + 0x4d bytes    
    user32.dll!___fnDWORD@4() + 0x24 bytes    
    ntdll.dll!_KiUserCallbackDispatcher@12() + 0x13 bytes    
    user32.dll!_NtUserMessageCall@28() + 0xc bytes    
    user32.dll!_DefFrameProcWorker@24() + 0x8f bytes    
    user32.dll!_DefFrameProcW@20() + 0x1b bytes    
    DpdfDesignerd.exe!CMDIFrameWnd::DefWindowProcW(unsigned int nMsg=161, unsigned int wParam=20, long lParam=460024) Line 188    C++
    DpdfDesignerd.exe!CWnd::WindowProc(unsigned int message=161, unsigned int wParam=20, long lParam=460024) Line 1742 + 0x1c bytes    C++
    DpdfDesignerd.exe!AfxCallWndProc(CWnd * pWnd=0x04256b68, HWND__ * hWnd=0x00120cfc, unsigned int nMsg=161, unsigned int wParam=20, long lParam=460024) Line 240 + 0x1c bytes    C++
    DpdfDesignerd.exe!AfxWndProc(HWND__ * hWnd=0x00120cfc, unsigned int nMsg=161, unsigned int wParam=20, long lParam=460024) Line 389    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_CallWindowProcAorW@24() + 0x51 bytes    
    user32.dll!_CallWindowProcW@20() + 0x1b bytes    
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::HookChainsWindowProc(unsigned int nMessage=161, unsigned int & wParam=20, long & lParam=460024) Line 213 + 0x20 bytes    C++
    DpdfDesignerd.exe!CExtHookSink::HookChains_t::g_HookWndProc(HWND__ * hWnd=0x00120cfc, unsigned int nMessage=161, unsigned int wParam=20, long lParam=460024) Line 271 + 0x14 bytes    C++
    user32.dll!_InternalCallWinProc@20() + 0x28 bytes    
    user32.dll!_UserCallWinProcCheckWow@32() + 0xb7 bytes    
    user32.dll!_DispatchMessageWorker@8() + 0xdc bytes    
    user32.dll!_DispatchMessageW@4() + 0xf bytes    
    DpdfDesignerd.exe!AfxInternalPumpMessage() Line 183    C++
    DpdfDesignerd.exe!CWinThread::PumpMessage() Line 896    C++
    DpdfDesignerd.exe!CWinThread::Run() Line 625 + 0xd bytes    C++
    DpdfDesignerd.exe!CWinApp::Run() Line 894    C++
    DpdfDesignerd.exe!AfxWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020b76, int nCmdShow=1) Line 47 + 0xd bytes    C++
    DpdfDesignerd.exe!wWinMain(HINSTANCE__ * hInstance=0x00400000, HINSTANCE__ * hPrevInstance=0x00000000, wchar_t * lpCmdLine=0x00020b76, int nCmdShow=1) Line 33    C++
    DpdfDesignerd.exe!__tmainCRTStartup() Line 324 + 0x35 bytes    C
    DpdfDesignerd.exe!wWinMainCRTStartup() Line 196    C
    kernel32.dll!_BaseProcessStart@4() + 0x23 bytes    

It happens only in debug build, besides, not every time. Here is the actions sequence in my application that causes the problem:

1. Run with one opened document
2. Close this document, so there is no one opened
3. Open 6 documents one after another.
4. Close application

I have found similar questions in subject on General Forum and have read answers. That’s why I don’t know exactly whether it is a bug or it is my fault.
Why can it happen?
Please, help to understand & fix.
Thanks in advance.

Would you send us a stripped version of your project that reproduces the problem? Typically CExtHookSink-derived objects are detaching the window procedures correctly when catching the WM_DESTROY messages. Similar problems may occur when using a third party C++ core which also uses a window procedure replacement and the de-initialization sequence is broken.

It’s not so easy to strip project for sending you, but we are trying to prepare it. It may not be soon. :(

During the research according to this crash we noticed that it has appeared after we have upgrated to version 2.62. While version 2.54 - everything was ok! May be this knowledge will help you to find the problem more quickly.

We have just fixed it. Please contact us for the update by e-mail.

Dear Support:

I got the same crash core stacks when my program exit (SDI with mutiple window tabs). Could you also send me the fixed update to me by e-mail?
thomas@iTravel-Tech.com

Thanks a lot.

In my Code i try to use the feature to change the Language. Now i have a question.
If the Menubar is not docked and i select Menu/Exit, the command has no effect. The example LanguageSwitcher shows the same behavior.
I use Ver.2.62.

In a CExtGridCellString subclass I’ve overridden OnClick() to detect right button up and pop up a menu with, of course, subsequent actions depending upon selection from the menu.

How do go about getting the selection to be set to the cursor position, as though it were a left button event, before I bring my menu?

Well, after scratching my head a bit more, I came up with a solution: Override CExtGridWnd::OnRButtonUp() and call CExtGridWnd::OnLButtonDown() before calling the base member function. If anyone has a better solution, I’m willing to entertain suggestions.
Thanks.

Dear support,

I am using CExtCheckListWnd, and I don’t see how to make it match the theme of the paint manager.
Is it not possible? if not, when you do plan on doing it.

Regards,
Ron.

Dear Tech Support,

I am wondering if it’s safe to put a CView in a CExtControlBar. I have done this and it mostly works except for auto-hide and closing the app come up with asserts.

Thanks,
-Brett

Dear Support Team,

Do you plan to add support for normal CView (or CFormView) class support to your "printing and print preview (PPV) subsystem".

In fact, I already have my printing and preview code working but I use the classic MFC class which are not themed :-(

regards,
Fabien

I am now studying the Prof-UIS.
I have a question.
Why samples source have CDocument class?
How to add CDocument class at the sample especially "PageNavigator"

If you want to convert the SDI sample that comes with Prof-UIS into SDIDOCVIEW sample (or MDI into MDIDOCVIEW), you should implement the document class at first. Then you should make your view class so it is based on some MFC’s view classes. Then you should remove the old code for creating a view from the OnCreate() method of its parent frame window. Finally, you should update the application’s OnInitInstance() method and put the document template registration into there.

How to disable(make it invisible) CExtPropertyGridComboBoxBar and CExtPropertyGridToolBar in a property grid?

You can use a CExtPropertyGridCtrl-derived class in which the OnPgcCreateBars() method is overridden in a way that it is mainly similar to the original one but you should not create the CExtPropertyGridComboBoxBar window in it. Another way is to call CExtPropertyGridCtrl::GetChildByRTC() in order to get a pointer to the created CExtPropertyGridComboBoxBar window, hide it and finally call CExtPropertyGridCtrl::RecalcLayout().

I have 2 CExtControlBars that contain the same dialog type.
One floats, one docked in autohide mode.
When placing the cursor over the autohidden, it expands.
However, when expanding the floating CExtControlBar clips the expanding CExtControlBar.
The dialog class has clip children and clip siblings set to false.


When expanding an auto hidden CExtControlBar, how do I get it painted as the top window?

How can I set gray and hot images for the toolbar buttons? The gray buttons that are currently being drawn from the normal button image looks like a gray blob, I’d like to specify my own image.

Are there any sample apps that show this?

There is no such a sample at the moment but we will add it later. Did you try the solution we suggested in this thread?

Hello

For example I set ArabicSA language as current language in my application, which has a property sheet with serveral property pages. I set PSP_RTLREADING flag in constructors of all property pages and PSH_RTLREADING flag in constructor of the property sheet. But the sheet’s title has LTR layout. How can I Set RTL layout in a property sheet? And by the way, how I can do that in message boxes?

I see in different painting examples you consistantly create a CExtMemoryDC. but I don’t see where it is flipped or drawn the the display. Can you provide more information about this class?

Thanks,
Seth

I have a custom static control as part of a toolbar. This custom static control needs to be repainted when some options are changed. However when it (based on CStatic) Invalidate() s itself, its OnPaint never gets called. I tried trapping the OnPaint message in the owner (toolbar), but there is a comment not to call CExtToolControlBar::OnPaint and several other buttons don’t display properly.

Is there a proper way to get the custom control to repaint properly?

Hi !

I get a memory leak when I try to load a bitmap file with an invalid path.
I think it’s because of no CException (CFileException) are caught, and then, deleted

I supposed that’s the same case for CExtBitmap::SaveBMP_File

David

I’m getting weird behaviors from FromBitmap(hbitmap). Is there similar code in this function?

In v.2.64 we fixed a memory leak in the code that loads bitmaps when the CExtBitmap::LoadBMP_File() method is invoked with an invalid file path. You can either switch to version 2.64 or simply tell us and we will send you the latest ../Prof-UIS/Include/ExtCmdIcon.h and ../Prof-UIS/Src/ExtCmdIcon.cpp files from v.2.64.

Here’s my output :

[...]

   * * * TERMINATING DYNAMIC LIBRARY: ProfUIS version 2.62 * * * 
Detected memory leaks!
Dumping objects ->
f:\rtm\vctools\vc7libs\ship\atlmfc\src\mfc\strcore.cpp(141) : {30675} normal block at 0x0251D1E8, 33 bytes long.
 Data: <  >x            > EC 97 3E 78 10 00 00 00 10 00 00 00 01 00 00 00 
{30674} client block at 0x025649A0, subtype c0, 24 bytes long.
a CFileException object at $025649A0, 24 bytes long
Object dump complete.
The thread ’__tmainCRTStartup’ (0x8d0) has exited with code 0 (0x0).
The thread ’Win32 Thread’ (0x8f0) has exited with code 0 (0x0).
The program ’[3472] TestProfuis.exe: Native’ has exited with code 0 (0x0).

[...]

bData.extBmp.LoadBMP_File(strTemp.c_str(), false, false);

Please update the source code for the CExtBitmap::LoadBMP_Buffer(), CExtBitmap::LoadBMP_File() and CExtBitmap::SaveBMP_File() methods in the ../Prof-UIS/Src/ExtCmdIcon.cpp file:

bool CExtBitmap::LoadBMP_Buffer(
    LPCVOID pBuffer,
    UINT nByteCount,
    bool bMake32, //= false
    bool bEnableThrowException, // = false
    bool bResourceFormat // = false
    )
{
    ASSERT( pBuffer != NULL );
    try
    {
        Empty();
        CMemFile _file(
            (LPBYTE)pBuffer,
            nByteCount
            );
        if( ! LoadBMP_File(
                _file,
                bMake32,
                bEnableThrowException,
                bResourceFormat
                )
            )
            return false;
        return true;
    }
    catch( CException * pException )
    {
        if( bEnableThrowException )
            throw;
        pException->Delete();
    }
    catch( ... )
    {
        if( bEnableThrowException )
            throw;
    }
    return false;
}
 
bool CExtBitmap::LoadBMP_File(
    __EXT_MFC_SAFE_LPCTSTR strFilePath,
    bool bMake32, //= false
    bool bEnableThrowException, // = false
    bool bResourceFormat // = false
    )
{
    try
    {
        CFile _file(
            strFilePath,
            CFile::modeRead
            | CFile::typeBinary
            );
        return
            LoadBMP_File(
                _file,
                bMake32,
                bEnableThrowException,
                bResourceFormat
                );
    }
    catch( CException * pException )
    {
        if( bEnableThrowException )
            throw;
        pException->Delete();
    }
    catch( ... )
    {
        if( bEnableThrowException )
            throw;
    }
    return false;
}
 
bool CExtBitmap::SaveBMP_File(
    __EXT_MFC_SAFE_LPCTSTR strFilePath,
    bool bMake32, //= false
    bool bEnableThrowException, // = false
    bool bUseIndexedRLE // = true
    )
{
    try
    {
        CFile _file(
            strFilePath,
            CFile::modeCreate
                | CFile::modeWrite
                | CFile::typeBinary
            );
        return
            SaveBMP_File(
                _file,
                bMake32,
                bEnableThrowException,
                bUseIndexedRLE
                );
    }
    catch( CException * pException )
    {
        if( bEnableThrowException )
            throw;
        pException->Delete();
    }
    catch( ... )
    {
        if( bEnableThrowException )
            throw;
    }
    return false;
}

Dear Support,

Am I right to assume that SerializeState method saves the command usage statistics only?

Thank you,
Chris

Hello,

Whilst implementing CExtColorButton, I noticed the colour square is very small and the size is unchangeable. Is there anything I can do about this?

Thanks

Hi there,

While I love all the controls that come with this library, I also like to develop my own controls which are specialised for the interface I’m creating. Originally I used to use system colours to allow the interface to theme nicely with the users desktop. However, as the Prof-UI can be skinned to just about anything, I was wondering what’s the best way of allowing the colours in my controls to match the common colours of the skins in Prof-ui? Is it possible to manually draw things like the window background (which on some themes is a gradient) and suchlike?

Many thanks