Forum

Dear Support,

When I add customization to my main frame, texts that I add to toolbar buttons are not displayed. Same code, but without customization display the text I place in the command in m_sToolbarText on the button.

Is this a known bug? Is there a fix for this?

Thanks,

Ron.

Yes. You are right.

Buttons in a customizable toolbar or a menu use the CExtCmdItem::m_sToolbarText property only as initial text. Whether the text is visible or not, that is specified by the display style stored in CExtCustomizeCmdTreeNode objects. Display styles can be applied using the CExtCustomizeCmdTreeNode::ModifyFlags() API. There four styles: __ECTN_DISPLAY_DEFAULT_STYLE, __ECTN_DISPLAY_TEXTONLY_IN_MENU, __ECTN_DISPLAY_TEXTONLY_ALWAYS and __ECTN_DISPLAY_TEXT_AND_IMAGE. You can see appropriate menu radio items in the context menu displayed over toolbar buttons in the customize mode. The CMainFrame::_SetCmdStateTextAndImage() method in the BitmapEditor sample application demonstrates how to change the display style.

I’ve noticed that RGB/A icons drawn using Prof UIS don’t have as smooth edges as when drawn by MFC.  There seems to be a difference with how the alpha channel is processed.

Is there anything that can done  to improve this?

Please accept my apologies for thinking I knew better!  The following does indeed work :)

CExtBitmap::LoadBMP_Resource();

CExtBitmap::AlphaBlend();

I don’t think you are right.

The alpha channel is being handled by the Prof UIS API - but it is drawn darker than DrawIconEx() does.

The loaded icon is not being reduced to low colour & no image lists are needed to show the problem.

I am right in thinking Prof UIS has its own alpha-channel algorithms?  If so I believe the problem is either CExtBitmap::AssignFromHICON() or CExtBitmap::AlphaBlend().  This is easily demonstated by performing the steps I mentioned in my earlier post.

This may be a specific problem for a particular computer. Because nobody reported similar issue yet. The CExtBitmap::AlphaBlend() API uses the only available Win32 API for alpha channel output: the AlphaBlend() function from MsImg32.dll module. Other icon painting APIs should do the same.

The following draws the alpha channel correctly:

LoadImage()

DrawIconEx()

The following draws grey pixels around the edge that shouldn’t be there & gives a slightly jagged look

LoadImage()

CExtBitmap::AssignFromHICON()

CExtBitmap::AlphaBlend()

CExtToolControlBar, CExtGridWnd, etc. all draw icons incorrectly.

The problem can be hidden in the LoadImage() Win32 API or Windows image list APIs used by the AssignFromHICON() method. Both Win32 API may prefer a non-32-bit version of the icon image and choose a low color version instead. The solution is to never use ICO files and resources. Use 32-bit BMP and PNG files instead.

Prof-UIS fully manages BMP formats including the alpha channel. We need more details about what’s wrong with the icons in apps running on your PC.

I’ll post a sample project when I get a chance.

Prof UIS is definately processing the alpha channel, its just drawing the edges a bit darker than MFC does, giving a more jagged look.

The point value is not where you click.

Dear Support,

We create MDI tab in our main frame. In 2.92 it is not displayed. Same code in 2.90 does display the MDI tab.

This is the code with which we create the MDI tab in the OnCreate of the main frame:

        m_wndMdiTabs.Create(this, CRect(0, 0, 0, 0), UINT(IDC_STATIC),
            WS_CHILD|WS_VISIBLE|WS_CLIPSIBLINGS, nTabMdiPlacement);

        m_wndMdiTabs.ModifyTabWndStyleEx(0, __ETWS_EX_CLOSE_ON_TABS|__ETWS_EX_CLOSE_ON_SELECTED_ONLY);
        m_wndMdiTabs.ModifyTabWndStyle(0, __ETWS_ITEM_DRAGGING|__ETWS_EX_TAB_SHAPE_ITEM_DRAGGING);

What was changed? Is it a know bug? Can you please check and see if there is a problem there?

Thanks,

Ron.

There is a "feature" in MFC 8.0 and later. If you are using the standard IDC_STATIC constant as a dialog control identifier of some window which should be docked to some side of parent window, then the IDC_STATIC window is not docked and typically invisible. Please use any constant but IDC_STATIC.

While looking at the RichContentFeatures sample I realized hex Unicode values do not appear to be supported.



<html>



<head>



<title></title>



</head>



<body>



Greek Capital Theta Symbol: U+03F4 &#x03F4; &#1012;



</body>



</html>



The above HTML renders 2 Greek Capital Theta Symbols in other HTML renders (I.E. Firefox, Etc.). In the RichContentFeatures sample only the decimal Unicode value is rendered.



Any additional information you can provide regarding HTML Everywhere feature (rich content) & hex Unicode would be appreciated.

You are probably using a version older than 2.92. We updated the constant parser in Prof-UIS 2.93. Now it displays both Theta characters. Please drop us an e-mail to the support mail box so we will provide you with the source code update.

We are using Unicode configurations for both Prof-UIS & the RichContentFeatures sample. Unless I’m missing something both screen shots you attached display the problem. In both cases the hex Unicode values are not rendered. Pasting the HTML from the first post into a HTML file and opening it in IE or Firefox will display 2 Greek Capital Theta Symbols (opposed to only 1 (decimal Unicode) in the RichContentFeatures sample).

Hi,

With reference to the following post, please suggest a solution -

http://www.prof-uis.com/prof-uis/tech-support/general-forum/asserts-from-cextpaintmanagercextpaintmanager-and-cextcomboboxbaseonfilterpopuplistclose-69097.aspx#70002

Thanks in advance.

Hello,

Consider the ProfStudio example provided with your package. In Windows 7, whenever I dock the ProfStudio application to one of the vertical sides of the screen, everything goes well. However, if I change the current GUI scheme to one handled by ProfUIS (i.e., one of the Office schemes), the app changes its look-and-feel as expected, but is repositioned randomly on the screen. I would expect the position of the main frame in the new look-and-feel to be close if not identical to the previous one: this is the case anyway to any other application including those based on ProfUIS when the system-managed schemes are being used. Can you help please and address this issue?


Thank you,

Bogdan

The only way to avoid this is not to switch UI theme in left/right docked state. Microsoft does not provide any APIs to detect left/right docked states. These states are not recognizable via Win32 APIs. And we don’t know any other APIs.

Thank you for looking into this and for the explanation: based on your response, I have been able to solve it slightly differently on the application side.

We checked this issue. We cannot confirm it. We checked Windows 7 with Aero-glass, XP-like themed and 2000 like classic desktop settings. We checked Prof-UIS UI themes with/without non-client area theming. We redocked main frame window using mouse and/or Win+Left, Win+Right, Win+Up, Win+Down key combinations. Everything works OK. Please provide us with additional details about how to reproduce this issue.

Hello,

1. I added CExtCustomizeSite to the ProfStudio example. Everything works well if the docking windows are, well, docked... However, if I float one of the windows and then toggle the option "Large icons in toolbars" in the Customize dialog box, the buttons in the floating window don’t change as they should. Do you have any suggestion/workaround for that?

2. CExtCustomizeSite still doesn’t create a dialog box conforming to the GUI scheme.

Thank you,

Bogdan

All the toolbars change icon sizes in our tests. But we suspect inner toolbars inside docked control bars may keep old icon sizes. Please update the source code for this static function:

static void stat_RedrawFloatingFramesEx( CFrameWnd * pDockSite )
{
    ASSERT_VALID( pDockSite );
    struct friend_t : public CExtControlBar
    {
    friend void stat_RedrawFloatingFramesEx( CFrameWnd * pDockSite );
    };
CMap
    <    CMiniFrameWnd *,
        CMiniFrameWnd *,
        char,
        char
        >
    setMiniFrames;
ExtControlBarVector_t vBars;
INT nCountOfExtBars = friend_t::g_AllBars.GetSize();
    for( INT nExtBar = 0; nExtBar < nCountOfExtBars; nExtBar++ )
    {
        CExtControlBar * pControlBar = friend_t::g_AllBars[ nExtBar ];
        ASSERT( pControlBar != NULL );
        if( pControlBar->GetSafeHwnd() == NULL )
            continue;
        ASSERT_VALID( pControlBar );
        ASSERT_KINDOF( CControlBar, pControlBar );
        if( pControlBar->IsDockBar() )
            continue;
        CFrameWnd * pBarParentFrame = pControlBar->GetParentFrame();
        ASSERT_VALID( pBarParentFrame );
        if( pBarParentFrame != pDockSite )
        {
            CMiniFrameWnd * pFloatingFrame =
                DYNAMIC_DOWNCAST(
                    CMiniFrameWnd,
                    pBarParentFrame
                    );
            if( pFloatingFrame == NULL )
                continue;
            setMiniFrames.SetAt( pFloatingFrame, 0 );
        }
        if( pControlBar->m_pDockSite == NULL )
        {
            CExtToolControlBar * pToolBar = DYNAMIC_DOWNCAST( CExtToolControlBar, pControlBar );
            if( pToolBar != NULL )
            {
                CWnd * pWnd = pToolBar->GetParent();
                CRect rc;
                pWnd->GetWindowRect( &rc );
                pWnd->SendMessage( WM_SIZE, SIZE_RESTORED, MAKELPARAM(rc.Width(),rc.Height()) );
                pToolBar->_RecalcPositionsImpl();
            }
        }
    } // for( ; pos != NULL; )
POSITION pos = setMiniFrames.GetStartPosition();
    for( ; pos != NULL; )
    {
        CMiniFrameWnd * pFloatingFrame = NULL;
        char nDummy;
        setMiniFrames.GetNextAssoc(pos,pFloatingFrame,nDummy);
        pFloatingFrame->RecalcLayout();
        pFloatingFrame->RedrawWindow(
            NULL,
            NULL,
            RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE
                | RDW_FRAME | RDW_ALLCHILDREN
            );
    } // for( ; pos != NULL; )
}

This last version addresses all the concerns I had regarding the icon sizes. Thank you so much for your fix.

The CExtCustomizeSite class recomputes the layout only those toolbars which are registered as customizable. The CExtControlBar::stat_RedrawFloatingFrames() static method recomputes the layout of all the floating frame windows. Please override the CExtCustomizeSite::OnChangedToolbarIconSizeOption() virtual method. Your method should invoke the parent class method and CExtControlBar::stat_RedrawFloatingFrames() static method.

The customization dialog is not themed because it should look differently in comparison with main customizable UI elements. It’s also not themed in Microsoft’s applications.

Thank you for your quick response.

1. Unfortunately it doesn’t seem to work... I added the following code in Mainfrm.cpp

void
CMainFrame::OnChangedToolbarIconSizeOption ()
{
try
{
CExtCustomizeSite::OnChangedToolbarIconSizeOption();
CExtControlBar::stat_RedrawFloatingFrames(this);
}
catch(...)
{
}
}

and

    virtual void
OnChangedToolbarIconSizeOption ();

in MainFrm.h.
The method is being called (I stepped through it) but neither the floating dialog box nor the dialog box docked at the bottom of the main frame (with no other control above it) do not seem to adjust their buttons.
However, if I resize them manually afterwards, they redraw correctly (with big buttons).

I sent you an email with the snapshots of my tests. Is there anything I could do to help solving this problem?

2. Your argument regarding the look-and-feel of the Customize dialog box is fair enough: thank you for looking into it.

We confirm your task requires an improved version of the CExtControlBar::stat_RedrawFloatingFrames() method:

static void stat_RedrawFloatingFramesEx( CFrameWnd * pDockSite )
{
    ASSERT_VALID( pDockSite );
    struct friend_t : public CExtControlBar
    {
    friend void stat_RedrawFloatingFramesEx( CFrameWnd * pDockSite );
    };
CMap
    <    CMiniFrameWnd *,
        CMiniFrameWnd *,
        char,
        char
        >
    setMiniFrames;
ExtControlBarVector_t vBars;
INT nCountOfExtBars = friend_t::g_AllBars.GetSize();
    for( INT nExtBar = 0; nExtBar < nCountOfExtBars; nExtBar++ )
    {
        CExtControlBar * pControlBar = friend_t::g_AllBars[ nExtBar ];
        ASSERT( pControlBar != NULL );
        if( pControlBar->GetSafeHwnd() == NULL )
            continue;
        ASSERT_VALID( pControlBar );
        ASSERT_KINDOF( CControlBar, pControlBar );
        if( pControlBar->IsDockBar() )
            continue;
        CFrameWnd * pBarParentFrame = pControlBar->GetParentFrame();
        ASSERT_VALID( pBarParentFrame );
        if( pBarParentFrame == pDockSite )
            continue;
        CMiniFrameWnd * pFloatingFrame =
            DYNAMIC_DOWNCAST(
                CMiniFrameWnd,
                pBarParentFrame
                );
        if( pFloatingFrame == NULL )
            continue;
        setMiniFrames.SetAt( pFloatingFrame, 0 );
        if( pControlBar->m_pDockSite == NULL )
        {
            CExtToolControlBar * pToolBar = DYNAMIC_DOWNCAST( CExtToolControlBar, pControlBar );
            if( pToolBar != NULL )
            {
                CWnd * pWnd = pToolBar->GetParent();
                CRect rc;
                pWnd->GetWindowRect( &rc );
                pWnd->SendMessage( WM_SIZE, SIZE_RESTORED, MAKELPARAM(rc.Width(),rc.Height()) );
                pToolBar->_RecalcPositionsImpl();
            }
        }
    } // for( ; pos != NULL; )
POSITION pos = setMiniFrames.GetStartPosition();
    for( ; pos != NULL; )
    {
        CMiniFrameWnd * pFloatingFrame = NULL;
        char nDummy;
        setMiniFrames.GetNextAssoc(pos,pFloatingFrame,nDummy);
        pFloatingFrame->RecalcLayout();
        pFloatingFrame->RedrawWindow(
            NULL,
            NULL,
            RDW_INVALIDATE | RDW_UPDATENOW | RDW_ERASE
                | RDW_FRAME | RDW_ALLCHILDREN
            );
    } // for( ; pos != NULL; )
}

The floating resizable dialog boxes work now, thank you. Do you plan to add this function to the next release?

Unfortunately, the buttons of the dialog box docked at the bottom of the main frame (with nothing above) still do not change. See also the email I sent yesterday with a sample snapshot.

Bogdan

I am afraid the problem is slightly larger than expected: consider again the ProfStudio example to which one adds CExtCustomizeSite. I close all docking windows and all toolbars then I open lets say the Solution Explorer docking window and I dock it to the bottom of the main frame: now if I start toggling the button size in the Customize dialog box nothing happens. This is because no sizing or position changed message is sent to the Solution Explorer window and therefore the buttons stay unchanged until one resizes the main frame.

Still waiting for some answers....

Please download the following image created with Prof-UIS 2.92:
http://www.prof-uis.com/download/forums/tmp/NcDistanceToBorders.png
The left column contains dialog template resource editors in Visual Studio. The right column contains the same dialogs in a running app. Different Prof-UIS and Windows desktop themes provide different border and caption sizes. But the distances of controls to dialog borders are the same because of anchoring. We suspect this is the source of the problem. Prof-UIS loads a dialog of the same size independently of UI theme settings and expects the dialog controls to be anchored. Probably your dialog controls are not anchored and this causes some space in pixels near right and bottom borders.

You are wrong. This is not the problem.

I already sent you a sample showing the problem of these extra 10 pixels. Please read back all our mails on this topic, and you will find an application I sent you that reproduces this bug. Then, you said that you ’solved’ it by changing my code. I then told you that it did nothing to the application...

So, please, try and fix it, and not insist that it’s fine.

To sum it up:

1. in 2.90 when I placed a button toching the right side of the dialog, and anchored it, it appeared in the UI touching the right order.

2. In 2.92 when I placed a button toching the right side of the dialog, and anchored it, it appears 10 pixels left of the border.

Same behavior happens on the bottom border.

Now, we need every pixel in the dialog, not to talk about all dialogs are not symmetric anymore.

Please explain how to get the same behavior of 2.90 in 2.92.

If your dialog problem has some incorrect size, this problem is related to dialog template loading rather than to custom non-client area computations. Have you specified some custom font in the dialog template properties?

Please take a look at the following image we created for you:



You can open it in MSPAINT.EXE, set maximal zoom and turn on grid lines using Ctrl+G keys and take a look at red lines. This image shows equal non-client area borders. If some border in some UI theme is greater/smaller that it’s in other, then the same can be seen in the opposite border.

Dear Support,

Please explain how to get rid of these 10 extra pixels on the edges - they were not there in 2.90, and we don’t want them.

Thanks.

Hi,

I have a SDI application which is using CExtTabWhidbeyWnd to emulate MDI behavior. I also have a few CExtControlBar in the application.

Please suggest, how do I move focus from CExtControlBar to CExtTabWhidbeyWnd.

Thanks in advance.

The main frame window is responsible for handling the WM_SETFOCUS message and setting focus to the selected tab page window. Please check this.

The SetFocus() Win32 API or CWnd::SetFocus() method should be used to set focus to any window. Do you mean how to find the main frame and tab page container inside it? If yes, then AfxGetMainWnd() API returns a pointer to the main frame window and its child window with the AFX_IDW_PANE_FIRST dialog control identifier is the main SDI view that is the tab page container in your project.

Hi,

By default I think CExtCustomizeSite cannot be used with a tabbed toolbar. So, I registered the toolbars in the tabbed toolbar. But I faced these problems:

1- Right click menu doesnot show up on the tabbed toolbar, (I could open the customize menu from another toolbar in mainframe)

2- I could drag&drop icons on the same toolbar in the tabbed toolbar but could not drag an icon from the toolbar in one tab and drop it on the toolbar in another tab.

Could you help me solve these problems. Thanks.

I was asking about this long time ago and it is still problem for me. It seems recursive sorting of tree grid is very inefficient. In my case it seems to be about 5 times slower than populating the tree from scratch. It ruins my application performance.
Unfortunately it seems to be lot of work to recreate tree each time for me, because I’m selecting some columns from database, other are calculated and of course I would need to remember selected/focused/expanded/hidden cells, scroll positions plus it would change HTREEITEM handles.
Can you check the tree sorting please? There must be way to optimize it significantly. Maybe recreate tree internally with using existing cells and HTREEITEMs? Thank you.

Hi,

I have an application using a custom CDlgtab inherited from CExtTabPageContainerWnd. When I fill it with tabs, I don’t get the prev/next arrows when the number of tabs exceed the visible amount of tabs the containerwnd can show.
What do we need to do to enable the prev/next arrows?

Thanks in advance,

Carsten

By the way - the m_wndTab.ShowBtnTabListSet(true); doesn’t show the list button. The arrow buttons are there. Any suggestions?

Please take a look at the Tab Settings dialog page inside Resizable Bar 0 in the TabPages sample application. You can check the Show Tab List check box and tab list button will appear. The following method handles check box event:

void CTabManageDlg::OnCheckShowTabList() 
{
    CExtTabPageContainerWnd* pTabPageContainer = ((CExtTabPageContainerWnd*)GetParent()->GetParent());
    pTabPageContainer->ShowBtnTabListSet( m_CheckShowTabList.GetCheck()==1 );
}

I have tried the following styles to my tab window:
    m_wndTab.ModifyStyleEx(0,WS_EX_CONTROLPARENT,0);
    m_wndTab.ModifyStyle(0,WS_CLIPCHILDREN|WS_CLIPSIBLINGS,0);
    m_wndTab.EqualWidthsSet(false);
    m_wndTab.AutoHideScrollSet(false);
    m_wndTab.ShowBtnTabListSet(true);
    m_wndTab.ShowBtnScrollHomeSet(true);
    m_wndTab.ShowBtnScrollEndSet(true);

Nothing comes up, unfortunately. I have checked with the sample code provided.

The tab page container control displayed on the Tab Containers dialog page in the ProfUIS_Conrols sample application demonstrates visible scrolling buttons. We need to take a look at the entire tab page container initialization code, or, even better, you can send us a test project demonstrating how you initialize it.

Hi again,

We located the problem to the class we inherited from CExtTabPageContainerWnd. We are overriding the following callbacks:
void CTabPageContainerWnd::CTabWnd::OnTabWndUpdateItemMeasure()
void CTabPageContainerWnd::CTabWnd::OnTabWndDrawItem()

to be able to modify font on the tab. In the overridden methods we increase the tab size as well as the font. If I just use the normal CExtTabPageContainerWnd class, then we get the buttons as in the sample program.

So therefore my question is: How do we properly change tab fonts without removing the buttons on the right edge?

Another question - Are stacked tabs not supported? As on propertysheets: CPropertySheet::EnableStackedTabs

Best regards,

Carsten

Please override the CExtTabWnd::OnQueryFont() virtual method in your CExtTabWnd-derived class. Then make the tab page container using your custom tab window by overriding the following virtual method:

    virtual CExtTabWnd* OnTabWndGetTabImpl()
    {
        return new CExtTWPC < CYourTabWnd >;
    }

Are vertical list box tabs the sames as tabs oriented as left or right? Or do you have a sample showing the functionality?

Please take a look at the main dialog in the ProfUIS_Controls sample app.

Thank you, it worked when the OnQueryFont was overridden. Thank you very much.

One last thing; How do you disable scrolling for the first two pages (for example) in a tab container. So that they are always visible even though you scroll the remaining? I’m almost positive that I had it working at a time, but now I can’t find the methods to invoke this behavior with.

Best regads,

Carsten

Sticky tabs are not supported. We can regard this as a feature request.

The CExtTabPageContainerWnd::ShowBtn***() should be in the help. This is probably some help file compilation issue. Thank you for reporting it.
The tab item scrolling buttons can become hidden if you applied some other style incompatible with them. The __ETWS_EQUAL_WIDTHS and CExtTabPageContainerWnd::EqualWidthsGet() method force hide tab scrolling arrow buttons. This is demonstrated on the Tab Containers dialog page in the ProfUIS_Controls sample application.

I should say - I’m using the aqua theme

No wonder I couldn’t find this in the help - it’s undocumented.
However, it does unfortunately not work. I set these in the :OnInitDialog procedure of the parent dialog and nothing happens.
Any other things that should be invoked or?

Is it possible?

The ribbon bar can integrate with the themed window caption. But it completely removes the caption and window top border and places itself to the topmost side of the parent window. The ribbon bar emulates a window caption because it needs to put a quick access toolbar into there. This is probably not exactly what you need. Please provide us with more details about which kind of buttons you need and where exactly they should appear?

Windows can be parent to other windows such as buttons. But all the child windows are always clipped by the parent’s client area. The caption is not part of the client area and you cannot insert buttons into it. The only way to have buttons inside the caption is to emulate them. I.e. by painting button-like-shapes inside the caption and handle mouse messages to implement a button hover/click.

Hello,

I have modified an example from Profs-UIS 2.92, the MDI example. I have add a menu item, OpenFile, which call the WinApp::OpenFile() Method and only this. When this method is called, an error occurs, a display message with "Encoutenred an improper argument" and nothing else. I did this on Windows 7 and MS 2010. I don’t know if this error comes from Prof-UIS or other but this would be good if you could give me some ideas to solve this problem. I have had this error many times when trying to migrate from MS 2003 to MS 2010 a Profs-UIS 2.23 application on Windows XP.

Thanks in advance,

Paul

To avoid any misunderstanding ... could you send us a modified version of the sample application?

If I change the base class for the test_page_sheet from

class CTestDlg : public CExtNCW < CExtResizableDialog >

to

class CTestDlg : public CExtResizableDialog

the skin of the top frame does not work.

Can you tell me why this is happening?

Dear support team,

We would like to use the compiler option /MP to reduce compile times. Unfortunetly those project who link ProfUIS and ProfSkin library throw the error C2813 #import not supported with "/MP" during compilation. It is caused by #import "msxml.dll" in ExtSkinItem.h.

We are actually using ProfUIS version 2.89. The ProfSkin Library is used only to have png support for CExtBitmap. Do you have a solution fro this issue?

Thanks in advance.

Tosrten Schucht

we are planning to update the ProfUIS version in our software. Since we’d like to have the above fix included, could you tell me when you are planning to release the version 2.93 ?

We plan to release v.2.93 later this month.

This change is included into Prof-UIS source code. You can drop us an e-mail so we will provide you with Prof-UIS 2.93 latest source code download.

OK, I’ll try that.

Do you think this change could make it into the next ProfUIS Release?

Hi,

We see that the tooltip code is repeated in every control.

We would like to add some generic tooltip logic for all controls, but we cannot do it now because every class implements its own functions, for example, ActivateTooltip is written exactly the same for button, edit, combo-box and slider classes, the m_nAdvancedTipStyle member is repeated in 8 classes.

Can you please for future versions create some base class that will include all the tooltip related functions and members.

Thanks,

Ron.