Forum

I’ve a problem with using CPictureCtrl. I’ve set my application to Office Style and in one dialog, where a CPictureCtrl is included, the application crashes if I tried to open the window.

Was there an other handling oder an other class oder control to use?

Dear Support,

As I already mentioned in the past, I’m making a kind of FormEditor, heavily based on your FormEditor sample. You’ve already helped me a great deal with proper painting of the controls, and now with your classes and their handling of WM_PRINTCLIENT message my application works really nice.

I have a control of my own, a kind of Picture control which can present not just ico and bmp files, but also jpg and gif files. In my class I have handled the WM_PRINTCLIENT message to have the control properly drawn on the form, the handler works much the same as the handler for WM_PAINT message. In earlier versions of your PrintClient solution, this worked nicely, I received the message and handled it just fine. But now as I’ve tested my application overall, I realised that my control is not getting the message anymore. Do you suppress this message somewhere in your CExtLabel code or have I changed something in the meanwhile that could prevent the message to reach my control? I’ll try to insert this class in your FormEditor sample to see if the problem is on my side, I was just hoping in the meanwhile you could come up with something obvious I’m missing.

Thank you,
Chris.

We guess the problem is caused by how the WM_PRINT/WM_PRINTCLIENT messages are handled in the CExtLabel class. It simply does not print out its child windows. We fixed this. Please update the following method:

LRESULT CExtLabel::WindowProc(UINT message, WPARAM wParam, LPARAM lParam) 
{
#if (defined WM_UPDATEUISTATE)    
    ASSERT( WM_UPDATEUISTATE == 0x0128 );
#endif
    if( message == 0x0128 )
        return 0;
    if(    message == WM_ENABLE )
    {
        LRESULT lResult = CStatic::WindowProc(message, wParam, lParam);
        Invalidate();
        UpdateWindow();
        return lResult;
    }
    if( message == WM_PRINT || message == WM_PRINTCLIENT )
    {
        CDC * pDC = CDC::FromHandle( (HDC)wParam );
        CRect rcClient;
        GetClientRect( &rcClient );
        DoPaint( pDC, rcClient );
        HWND hWndChild = ::GetWindow( m_hWnd, GW_CHILD );
        for( ; hWndChild != NULL; hWndChild = ::GetWindow( hWndChild, GW_HWNDNEXT ) )
        {
            DWORD dwChildStyle = ::GetWindowLong( hWndChild, GWL_STYLE );
            if( (dwChildStyle&WS_VISIBLE) == 0 )
                continue;
            CRect rcChildWnd, rcChildClient, rcStartClient;
            ::GetClientRect( m_hWnd, &rcStartClient );
            ::ClientToScreen( hWndChild, ((LPPOINT)(&rcStartClient)) );
            ::ClientToScreen( hWndChild, ((LPPOINT)(&rcStartClient))+1 );
            ::GetWindowRect( hWndChild, &rcChildWnd );
            ::GetClientRect( hWndChild, &rcChildClient );
            ::ClientToScreen( hWndChild, ((LPPOINT)(&rcChildClient)) );
            ::ClientToScreen( hWndChild, ((LPPOINT)(&rcChildClient))+1 );
            CPoint ptChildRenderOffset( 0, 0 );
            if( (lParam&PRF_NONCLIENT) != 0 )
            {
                ptChildRenderOffset.x = rcStartClient.left - rcChildWnd.left;
                ptChildRenderOffset.y = rcStartClient.top - rcChildWnd.top;
            }
            else
            {
                ptChildRenderOffset.x = rcStartClient.left - rcChildClient.left;
                ptChildRenderOffset.y = rcStartClient.top - rcChildClient.top;
            }
            if(     ptChildRenderOffset.x != 0
                ||  ptChildRenderOffset.y != 0
                )
                ::OffsetViewportOrgEx(
                    pDC->m_hDC,
                    -ptChildRenderOffset.x,
                    -ptChildRenderOffset.y,
                    NULL
                    );
            ::SendMessage(
                hWndChild,
                message,
                (WPARAM)pDC->m_hDC,
                lParam
                );
            if(     ptChildRenderOffset.x != 0
                ||  ptChildRenderOffset.y != 0
                )
                ::OffsetViewportOrgEx(
                    pDC->m_hDC,
                    ptChildRenderOffset.x,
                    ptChildRenderOffset.y,
                    NULL
                    );
        }
        return (!0);
    }    
    if(     message == WM_SETTEXT 
        ||  message == WM_GETTEXT 
        ||  message == WM_GETTEXTLENGTH 
        )
    {
        DWORD dwWndStyle = GetStyle();
        DWORD dwWndType = (dwWndStyle&SS_TYPEMASK);
        if(     dwWndType == SS_BLACKRECT 
            ||  dwWndType == SS_GRAYRECT 
            ||  dwWndType == SS_WHITERECT 
            ||  dwWndType == SS_BLACKFRAME 
            ||  dwWndType == SS_GRAYFRAME 
            ||  dwWndType == SS_WHITEFRAME 
            ||  dwWndType == SS_USERITEM 
            ||  dwWndType == SS_OWNERDRAW 
            ||  dwWndType == SS_BITMAP 
            ||  dwWndType == SS_ICON
            ||  dwWndType == SS_ENHMETAFILE 
            ||  dwWndType == SS_ETCHEDHORZ 
            ||  dwWndType == SS_ETCHEDVERT 
            ||  dwWndType == SS_ETCHEDFRAME 
            )
            return CStatic::WindowProc( message, wParam, lParam );
 
        LRESULT lResult = FALSE;
        if(     (!m_bInitText)
            &&  (message == WM_GETTEXT || message == WM_GETTEXTLENGTH)
            )
        {
            lResult = CStatic::WindowProc( message, wParam, lParam );
            INT nMaxLength = 0;
            if( message != WM_GETTEXTLENGTH )
            {
                WPARAM wParamLocal = 0L;
                LPARAM lParamLocal = 0L; 
                nMaxLength = (INT)
                    CStatic::WindowProc( 
                        WM_GETTEXTLENGTH, 
                        wParamLocal, 
                        lParamLocal 
                        );
            }
            else
                nMaxLength = (INT)lResult;
            CString sTextInit;
            CStatic::WindowProc( 
                WM_GETTEXT, 
                nMaxLength + 1, 
                (LPARAM)sTextInit.GetBuffer( nMaxLength + 1 ) 
                );
            sTextInit.ReleaseBuffer();
            m_sText = sTextInit;
            m_bInitText = true;
            return lResult;
        }
        if( message == WM_SETTEXT )
        {
            LPCTSTR lpszText = (LPCTSTR)lParam;
            m_sText = lpszText;
            m_bInitText = true;
            RedrawWindow(
                NULL, NULL,
                RDW_INVALIDATE | RDW_ERASE | RDW_UPDATENOW | RDW_ERASENOW
                );
            lResult = TRUE;
        }
        else if( message == WM_GETTEXT )
        {
            TCHAR * lpszText = (TCHAR *)lParam;
            ::memset( lpszText, 0, wParam );
            __EXT_MFC_STRNCPY(
                lpszText,
                wParam,
                m_sText,
                wParam - 1
                );
            lpszText[ wParam - 1 ] = _T(’\0’);
            lResult = TRUE;
        }
        else if( message == WM_GETTEXTLENGTH )
        {
            lResult = m_sText.GetLength();
        }
        return lResult;
    }
    return CStatic::WindowProc(message, wParam, lParam);
}

I wasn’t clear in my first post: My Picture control is a class derived from CExtLabel, not a child of a CExtLabel object. So your fix didn’t solve my problem.

I solved the problem by overriding WindowProc, catching WM_PRINT and WM_PRINTCLIENT messages and doing all rendering there.

But I’m still interested why my original idea didn’t work. I made a function afx_msg LRESULT OnPrintClient(WPARAM wParam, LPARAM lParam); and had the lines ON_MESSAGE(WM_PRINTCLIENT, OnPrintClient) and ON_MESSAGE(WM_PRINT, OnPrintClient) in the message map. But OnPrintClient function never got called. What could be the reason for that? Do I have to call some other macro in the message map instead of ON_MESSAGE? I also have ON_WM_PAINT in the same message map and that works just fine.

By the way: Happy New Year! :)

Dear Support,

In your FormEditor sample there is a little drawing mistake:
When I have a control on the form and I select the control, there are eight little gripboxes drawn to the sides and corners of the control. I open any dialog over the application, which covers the control partially or fully. When I close the dialog, the grip boxes that were under the dialog get drawn to wrong places. The same happens when I’m moving the dialog fast over the control. Also the caption and the borders of the form is drawn a little shattered with some of the themes, when the dialog is moved or closed over it. Could you advise, please?

Thank you,
Chris.

Dear Support,

I have 2 questions related to PropertyGrid’s indenting.

1. I have some compound property values. The names of the children of the compound property are indented a little bit, not starting at the left side of their cells. I can see this also in your CompoundProperty sample, but in that sample I can’t see any option that would change this appearance. Is there a way I can have the name cells of these compound-part properties not indented? (this problem relates to the text’s indenting inside the cell)

2. Also I have a category with some compound properties inserted into it (you also have that in your CompoundProperty sample). If I set the CExtPropertyGridWndCategorized grid’s m_nConstantIndent value to -1, the indent should depend on every item’s nested level, as the Help says. This works great in your PropertyGrid sample with the simple properties inserted into some category, but in the CompoundProperty sample with the compound properties, I can’t see the indent acting as supposed to. The compound properties are indented to the same level as the category they are inserted into. Is it intentional to behave like that? (this problem relates to the cell’s indenting inside the grid)

Thank you for all your help,
Chris

The m_nConstantIndent property is related to the indent of property categories. There is no built-in property for compound property indent and that is why you cannot find such check boxes in the CompoundProperties sample. If you have more than two nested levels of property categories we would not recommend you remove indents. We did not implement the possibility controlling indentation for compound properties because very large and very small indents make them less user friendly.

I didn’t really understand what you were trying to suggest to me in your last post. I don’t have more than 2 nested levels of property category. Here’s a picture of what my property control looks like.

As you can see, the compound property ("First Text") is indented the same as its parent ("Text" category) and also the same as the compound property on root level ("Bounds"). This is little confusing. I’d like "First Text" to be indented one more level. Meaning: indention should be counted from the tree box of the compound value, not the text of it. The compound property on root level acts like this, but the compound property on lower levels does not.

Everything I wrote in this post refers to question #2 of my first post. Please, forget about question #1.

Hi,

I followed the steps described in the FAQ : "How to disable resizing a resizable control bar"
(http://www.prof-uis.com/FAQView.aspx?CID=97#FAQ351)

It works fine until I dock a control bar into another, then itaˆ™s no longer a CExtControlBar
but a CExtDynControlBar container, and my overriden methods are not called.

So I overrided the same methods in a CExtDynControlBar-derived class.

Iaˆ™m stuck here :

I read that it is not possible to replace the CExtDynControlBar class with mines
(http://www.prof-uis.com/Forum_View.aspx?CID=29&M=5183)
like handling of registered windows messages for the CExtDynTabControlBar class.

What should i do ?

Thanks in advance

thanks for your reply,

The problem is that my control bar container I want resizing disabled is not a tab container.
I created it like this :

m_wndResizableBarEmpty.Create(...)
m_wndResizableBarCP.Create(...)
...
m_wndResizableBarCP.DockControlBar(AFX_IDW_DOCKBAR_RIGHT, 2, this);
m_wndResizableBarCP.DockControlBar(&m_wndResizableBarEmpty, true, true);

When I drag the border of this container and I break in CExtControlBar::OnNcLButtonDown,
this = CExtDynControlBar

It’s not a tabbed container, am I wrong ?

thanks

We would not recommend you using CExtControlBar::DockControlBar() for setting up initial locations of control bars. You could use the CExtControlBar::DockControlBarInnerOuter() and CExtControlBar::DockControlBarLTRB() methods instead.

I have an existing toolbar that I would like to add tooltips to. But I can’t figure out how to do it. I looked at some sample code, but it’s doing things with CExtCustomizeSite that I haven’t a clue about. I really can’t begin to figure out how to integrate CExtCustomizeSite into an existing app.

Is there an easy way to add tooltips to each button in my CExtToolControlBar?

The toolbar button tooltips in both customizable and non-customizable applications are not properties of toolbar buttons. The tooltips are properties of the command objects stored in the command manager:

CExtToolControlBar & wndToolBar = . . .
INT nButtonIndex = . . .
CExtBarButton * pTBB = wndToolBar.GetButton( nButtonIndex );
    if( pTBB == NULL )
        return . . . // if nButtonIndex specifies invalid index
    ASSERT_VALID( pTBB );
    if( pTBB->IsSeparator() )
        return . . . // if toolbar button at nButtonIndex position is separator
UINT nCommandID = pTBB->GetCmdID( false );
    if( ! nCommandID::IsCommand( nCommandID ) )
        return . . . // if some specific toolbar button
CExtCmdItem * pCmdItem = g_CmdManager->CmdGetPtr( g_CmdManager->ProfileNameFromWnd( wndToolBar.GetSafeHwnd() ), nCommandID );
    if( pCmdItem == NULL )
        return . . . // if command is not registered in the command manager (normally this should not occur)
    pCmdItem->m_sTipTool = _T("This is the tooltip text");

Ah, okay. My toolbar has more than 16 colors, so I had to edit the string table directly, but thanks for the help.

I have another question regarding toolbars in our application. We create 2 toolbars in our application:


    if ( !m_wndContentViews.Create( L"Content Toolbar", this, AFX_IDW_TOOLBAR,
        WS_CHILD | CBRS_RIGHT | CBRS_GRIPPER | CBRS_FLYBY | CBRS_SIZE_DYNAMIC | CBRS_TOOLTIPS ) ||
        !m_wndContentViews.LoadToolBar( IDR_CONTENT_VIEWS ) )
    {
        TRACE0("Failed to create content view toolbar\n");
        return -1; // failed to create
    }

    m_wndContentViews.EnableDocking( CBRS_ALIGN_ANY );

    if ( !m_wndCollectionToolbar.Create(L"Collection Toolbar", this, AFX_IDW_TOOLBAR,
        WS_CHILD | CBRS_RIGHT | CBRS_GRIPPER | CBRS_FLYBY | CBRS_SIZE_DYNAMIC | CBRS_TOOLTIPS ) ||
        !m_wndCollectionToolbar.LoadToolBar( IDR_COLLECTION_TOOLBAR ) )
    {
        TRACE0("Failed to create collection tab toolbar\n");
        return -1; // failed to create
    }

    m_wndCollectionToolbar.EnableDocking( CBRS_ALIGN_ANY );


We initially hide both toolbars and only display them when certain tabs are displayed in our tab container. However if you right click the toolbar, you get a menu that looks like this:

Toolbar
Toolbar

However, no matter which menu item you select, it only controls m_wndContentViews. No option exists for our 2nd toolbar. Furthermore, on the View menu, there’s only one Toolbar menu item and it only controls wndContentViews.

How can we either fix the menu so it works correctly or just remove the toolbars from all menus (popup and View).

The problem is the 3rd parameter of the Create method. It should be an ID which identifies the created toolbar. You have to use a different ID for each and every toolbar.

You can exclude any control bar (toolbar, menu bar, control bar, or panel bar) from the menu with the list of all control bars created in the frame window using this code:

m_wndBar.m_bAppearInDockSiteControlBarPopupMenu = false;

Looks like an infinite loop is happening in the Skinable sample project before the window is ever displayed if a parent control is a disabled control with children. Saw a similar problem posted here for unchecking controls. To fix bring up Prof-UIS dll project and open extbutton.cpp, find the CExtRadioButton::WindowProc method. Insert line in code snippet below and build:

LRESULT CExtRadioButton::WindowProc(UINT message, WPARAM wParam, LPARAM lParam)
{
    if( message == WM_GETDLGCODE )
        return (DLGC_BUTTON | DLGC_RADIOBUTTON);

    if( message == BM_SETCHECK )
    {
        LRESULT lRes = CExtCheckBox::WindowProc( message, wParam, lParam );
        CWnd * pWndParent = GetParent();
        ASSERT_VALID( pWndParent );
        
        if( !this->IsWindowEnabled() ) return lRes; //INSERT THIS LINE!!!
...

Thanks,
Wes Garrard

Dear Tech Support,

I am using CExtCustomizeSite in my application. When I add a new menu item via the resource editor in developer studio, the new menu item does not show up until I delete the saved custom state in the registry.

Is there a way to get it to show up without having to delete the saved state in the registry?

Thanks,
-Brett

Your new commands are not present in the GUI state loaded from the registry and they are treated as though as they were removed from a toolbar by the user. The same is true for pop-up menus. You can simply reset your toolbars in the Customize dialog rather than remove the registry settings.

Is there a way to reset the toolbars/menus programmatically, rather than require the user to do this? If so, is there also a way to programmatically reset only certain items in a toolbar and/or menu?

Thanks

Hi,

I currently work with Prof-UIS v2.62 in MSVC++ 7.1.
I found a minor issue that can be reproduced using one of your samples.

Launch MDI_DynamicBars-m.exe
Just move 3 docks in a corner of the screen and don’t care about the rest of the application.
Let’s call the 3 docks A, B and C
Make them all dockable
TabDock B in A
And let C in a floating position.
Apply size process using the size grip on C and observe that the child window inside the docks repaints fast.
Now Apply the size process on B (or A depending witch tab is selected ) and observe that the child windows repaints really slowly compared to C.

Do you think you can fix this issue because in my application i use a lot of docks.
This issue exists with at least two tabbed docks but its slower and slower with more tabbed docks.
Try to complete the tab switcher with around ten more docks and apply the size process, it becomes unusable :(

Best Regards

Dear Support,
Still waiting any kind of response.

Regards,
Damien.

We are sorry for the delay. To fix this issue, we need to redesign the CExtMiniDockFrameWnd class that represents a floating mini frame window, a container for floating control bars. It is scheduled to be available in the next version.

Dear Support,

I know that the original Windows control of type ComboBox does not allow to change the text of any inserted item. I was just wondering if your CExtComboBoxBase class made this work through its LB_ITEM list. I tried this code, but it didn’t change anything.
pCombo->LbItemGet(i)->LbItemCellGet(0)->m_sItemText = strNewText;
Are you planning on implementing such feature?

Thank you,
Chris.

Please make sure that your combo box is owner drawn.

Actually it is your CExtPropertyGridComboBoxBar, so it’s not owner drawn. I change the name of some PropertyStore as a result of a message in runtime and I was just trying to reflect that change in the ComboBox as well. Since I couldn’t change the text, right now my code removes the PropertyStore and inserts it again, now with the correct name. I was just wondering if I could just change the text in the ComboBox’s list.

Integration Wizard is creating an exception when executing. Where do I find IntegrationWizard source code so that I can debug the problem?

Dear Support,

When you right-click and the bars list menu appears, and you are too close to the bottom of the screen, the menu bar is relocated so that it won’t be displayed partially.

This feature is required. However, when this happens, the menu is closed too fast, before the user get the chance to select a command from the menu.

Regards,
Ron.

Dear Tech Support,

I have a dialog in my application that uses the ON_NOTIFY(TVN_KEYDOWN, ...) message map, but none of the keys that have been defined in the accelerator table get sent there (they’re only sent to the mainframe).

Is there a way to force keypresses that have been defined in the Accelerator table to go to the currently focused dialog?

Thanks,
Brett

In the CMainFrame::PreTranslateMessage() method of your project, you should analyze if the focused window is the tree control that requires all key input. In this case you should not invoke the parent class method:

BOOL CMainFrame::PreTranslateMessage( MSG * pMsg )
{
    if( WM_KEYFIRST <= pMsg->message && pMsg->message <= WM_KEYLAST )
    {
        HWND hWndYourTreeControl = ...
        HWND hWndFocus = ::GetFocus();
        if( hWndFocus == hWndYourTreeControl )
            return FALSE;
    }
    return PARENT_CLASS::PreTranslateMessage( pMsg );
}

Is there a way to specify the initial color selection mode (e.g. MODE_RGB_CUBE) for the standard CExtColorDlg, prior to a doModal call?

Dear Support,

I have a document with a propertystore, which has both CExtPropertyValue-s and CExtPropertyValueCompound-s inserted into it. When I save my document I want to set the default values to be the current active values, to reflect this save. For this I iterate through the PropertyStore’s items and call ValueDefaultFromActive for each of them. This works great for the pure CExtPropertyValue items, but not for the CExtPropertyValueCompound ones.
I tried to do the same thing in any of your samples, but CompoundProperties only has CExtPropertyValueCompound items, and PropertyGrid sample only has CExtPropertyValue items. Although, I can see the same behaviour in these samples, meaning PropertyGrid works fine, but CompoundProperties does not.

Could you please check this issue?

Thank you for all your help,
Chris.

Hello.

I can link Static Lib Prof-uis to an Exe module.

However, a Dll module can link it, too, but demands prof-uis254md.dll.

I do not use prof-uis for exe starting dll.

It’s not exactly clear for me what you are asking, but this article about Prof-UIS Build Configurations might give you the answer you need.

Dear Support,

Again I’m having problems with CExtRadioButtons and their tabbing. I have a CExtResizableDialog and I’m creating some controls to it dynamically. When creating a CExtRadioButton-group, taborder stops working as should be. I made a little sample to demonstrate the situation. In dialog class’ .cpp file I made some defines, you only have to change those to test different behaviour of pure MFC and Prof-UIS controls. At first startup the correct behaviour can be seen with MFC.

Thank you,
Chris

I am getting assertion failure when I am creating a dialog with more than one tab pages on it. And that dialog is placed on a dialogbar. Please note that I can not use your CExtControlBar because of the incompatibility with MFC control bars.
I have attached the sample project by mail. Please reply as soon as possible.

First, remove the following lines from the CChildDlg’s message map, because these controls do not exist:

DDX_Control(pDX, IDOK, m_BtnOK);
DDX_Control(pDX, IDCANCEL, m_BtnCancel);

The second error is caused by that you did not specify the class name for the IDC_TAB_CONTAINER custom control. The class name should be ProfUIS-TabPageContainer.

Please note because you are using the CControlBar instead of CExtControlBar, you have to manually resize the CChildDlg dialog to fit the control bar client area.

Hi,

We’ve noticed a problem (yes, again ˆˆ) in the CExtGridWnd::SiwModifyStyle method.
If we set either the __EGBS_SFB_FULL_ROWS style or __EGBS_SFB_FULL_COLUMNS, the result is the same : we always get a full column selection.

Thank you for your answer.

Aurelien Loizeau

Hi to all,
I have a simple question: state of the art of Report Grid printing framework (you have promise many month ago).


TX

The print preview feature for the CExtGridWnd, CExtTreeGridWnd and CExtReportGridWnd classes is under development and will be available in the next release. Please download the application below that demonstrates this feature (invoke File | Print Preview menu):

PrintPreview

OK, that’s very very good.
When you plan to release next version?


Thanks a lot again