Forum

The CExtHyperLinkButton supports two modes:

1) The default mode. The click on the hyperlink button opens the associated URL.

2) The command mode. The click on the hyperlink button sends the WM_COMMAND message like the CExtButton push button control does. To switch the hyperlink button into this mode you should set its CExtHyperLinkButton::m_bUseStdCommandNotification flag property to true.

The second type of hyperlink button can be configured for displaying popup menu instead of sending the command message:

CExtHyperLinkButton & wndHyperLink1 = . . .
            wndHyperLink.m_bUseStdCommandNotification = true;
CMenu _menu;
            VERIFY( _menu.LoadMenu( IDR_YOUR_POPUP_MENU_RESOURCE ) );
            wndHyperLink.m_menu.Attach( _menu.Detach() );

The CExtHyperLinkButton supports two modes:

1) The default mode. The click on the hyperlink button opens the associated URL.

2) The command mode. The click on the hyperlink button sends the WM_COMMAND message like the CExtButton push button control does. To switch the hyperlink button into this mode you should set its CExtHyperLinkButton::m_bUseStdCommandNotification flag property to true.

The second type of hyperlink button can be configured for displaying popup menu instead of sending the command message:

CExtHyperLinkButton & wndHyperLink1 = . . .
            wndHyperLink.m_bUseStdCommandNotification = true;
CMenu _menu;
            VERIFY( _menu.LoadMenu( IDR_YOUR_POPUP_MENU_RESOURCE ) );
            wndHyperLink.m_menu.Attach( _menu.Detach() );

Hi,

how can i join the corner of a CExtGridWnd (the red rectangle in the image)?

Thanks

Ulrich

Using profuis 2.87.

Hi,

We want to use the CExtNCSB template for skinning the scrollbars of some of our custom controls. These controls use the SB_LINE and SB_PAGE codes of the scrollbar’s WM_VSCROLL message.

We noticed these codes no longer are sent by the scrollbar while using CExtNCSB.

According to the profuis documentation "The CExtScrollBar class extends the functionality of the MFC’s CScrollBar class".

Unfortunately this is not the case. It breaks the CScrollBar functionality, because in your infinite wisdom you have decided to no longer send the SB_LINE and SB_PAGE messages, but instead only send the SB_THUMB messages.

Somewhere in this forum you have justified this by saying that it is handy as you then always have the current scrollposition. It’s NOT!

The whole point of the SB_LINE and SB_PAGE messages is to allow the parent control to decide what to do with the scrollposition.

By only sending the SB_THUMB messages you break the default behaviour of the CScrollBar, making the CExtScrollBar useless as a replacement for CScrollBar in existing applications that just want the skinning capabilities of ProfUis.

As you also use the CExtScrollBar for the CExtNCSB template, this template is also quite useless.

Could you please fix CExtScrollBar and CExtNCSB  so that it behaves just like the CScrollBar or create another class that has that behaviour?

 

 

We always use the SetScrollInfo() Win32 API first. If it returns an error, then we use very old style 16-bit APIs. This provides compatibility with old Windows versions.

The point I was trying to make is that SetScrollInfo does not update the trackposition.

Therefore calling SetScrollInfo during the handling of a SB_THUMBTRACK notification is rather pointless.

Code that relies on the scrollinfo to be correct during their own handling of SB_THUMBTRACK then will no longer function correctly without modification.

This makes the use of CExtNSCB as a drop-in replacement for skinned scrollbars rather difficult.

This is not a bug. The SetScrollInfo() Win32 API does not cause any messages to be sent and we simply cannot get notified when your code invokes it. Please invoke the NCSB_RescanContainers() API in your CExtNCSB-based class method which invokes the SetScrollInfo() Win32 API.

I’m sorry to here this. I was hoping CExtNSCB could intercept the SetScrollInfo somehow and update itself accordingly.

 

Very unfortunately, there is no such notification. The scrolling is even worst in the particular case. For example, we can find the scrollable window inside the Internet Explorer Active X control and this window understands the WM_HSCROLL / WM_VSCROLL messages, but the GetScrollInfo() Win32 API returns zero values. We cannot skin the scroll bars of the Internet Explorer Active X control without accessing its automation APIs for hacking its mystic scrolling implementation. The alternative (and not the best) solution is to run some 100-200 milliseconds period based timer which will invoke the GetScrollInfo() API for scanning the scrolling state changes.

Well, I’m glad you gave it some thought anyway and I thank you for the solution you gave me.

But I still would like to know if this solution will be part of future ProfUis releases, because I don’t want to have to patch new releases.

 

Yes, it’s already part of Prof-UIS. You can drop us an e-mail to the support mail box at this web site and we will provide you with the latest Prof-UIS 2.90 download information.

The scroll bar action notifications are supported but we didn’t sent them because they are not working with most of the common controls. The CExtNCSB template class is the most often used with common controls. But it’s not a problem to provide the scroll bar’s action notifications by default and do not provide them for the automatically detected common controls. Please update the source code for the following method:

CExtScrollBar * CExtNCSB_ScrollContainer::OnInstantiateAndCreateScrollBar( bool bChildMode )
{
            ASSERT_VALID( this );
            if( GetSafeHwnd() == NULL )
                        return NULL;
e_mode_t eMode = GetMode();
            if( ! ( eMode == __EM_HORIZONTAL_SCROLL_BAR || eMode == __EM_VERTICAL_SCROLL_BAR ) )
                        return NULL;
CExtScrollBar * pWndScrollBar = NULL;
            try
            {
                        TCHAR szCompare[512] = _T("");
                        ::GetClassName( m_hWndScrollingTaget, szCompare, sizeof( szCompare ) / sizeof( szCompare[0] ) );
                        pWndScrollBar = new CExtScrollBar;
                        if(                     _tcsicmp(  szCompare, _T("edit") ) == 0
                                    ||           _tcsnicmp( szCompare, _T("riched"), 6 ) == 0
                                    ||           _tcsicmp(  szCompare, _T("listbox") ) == 0
                                    ||           _tcsicmp(  szCompare, _T("combolbox") ) == 0
                                    ||           _tcsicmp(  szCompare, _T("systreeview32") ) == 0
                                    ||           _tcsicmp(  szCompare, _T("syslistview32") ) == 0
                                    )
                        {
                                    pWndScrollBar->m_bAlwaysSendThumbButtonNotifications = true;
                                    pWndScrollBar->m_bSendActionNotifications = false;
                        }
                        if( ! bChildMode )
                        {
                                    pWndScrollBar->m_bPopupInactiveLightMode = true;
                                    pWndScrollBar->m_bEnableHookSpy = true;
                                    pWndScrollBar->m_nMouseActivateCode = MA_NOACTIVATE;
                        }
                        CRect rc;
                        GetClientRect( &rc );
                        if( ! pWndScrollBar->Create(
                                                WS_CHILD|WS_VISIBLE|WS_CLIPCHILDREN|WS_CLIPSIBLINGS
                                                            | ( ( eMode == __EM_HORIZONTAL_SCROLL_BAR ) ? SBS_HORZ : SBS_VERT )
                                                            ,
                                                rc,
                                                this,
                                                UINT(__EXT_MFC_IDC_STATIC)
                                                )
                                    )
                                    return NULL;
                        return pWndScrollBar;
            }
            catch( CException * pException )
            {
                        pException->Delete();
            }
            catch( ... )
            {
            }
            if( pWndScrollBar != NULL )
                        delete pWndScrollBar;
            return NULL;
}

Hi



Thanks for the solution.

Will this solution also be present in future releases of ProfUis?

I’m always a bit wary to just implement proposed fixes in the Profuis source code, as I don’t know if these fixes also will be available in the next ProfUis version.



We are using a third-party control that relies on the correct function of the scrollbars and their notifications.

I now get the SB_LINE & SB_PAGE notifications, which is fine, but there is however another bug.

What we are seeing is that, when using CExtNCSB, the SCROLLINFO of the control has not been updated correctly when the SB_THUMBTRACK notification arrives.



To test this, we call GetScrollInfo(SB_VERT, &si, SIF_ALL) when the SB_THUMBTRACK notification arrives (via WM_VSCROLL), with si a SCROLLINFO.

We notice that the si.nTrackPos that is returned is NOT the trackpos as given by the position in the wParam argument of the WM_VSCROLL message generated by CExtNCSB.

Instead the trackpos is the same as the si.nPos.

This is different from the normal behavior of a scrollbar. The trackpos must be different from si.nPos, it must be the same as the wParam argument hiword.



I’ve digged somewhat in the CExtScrollBar and CExtNCSB code and found out that you synchronize the control’s scrollinfo with the CExtScrollBar in the ncsb scrollbar container and vice versa via a call to SetScrollInfo() (via NCSB_UpdateChannel) but only AFTER the WindowProc of control has handled the WM_VSCROLL message.

I tried to synchronize the control’s scrollinfo by calling NCSB_UpdateChannel in the WM_VSCROLL handler, but to no avail.

Unfortunately it is not possible to set the trackpos via SetScrollInfo (see the MSDN docs of the SetScrollInfo Function).



Maybe you can find another way of fixing this problem, because now if not, then this means that your solution with CExtNCSB does not work for all controls and may even not work for some of the common controls in all cases.



PS:

I also found what I think is a bug in CExtNCSB_Impl::NCSB_SetScrollInfoWindow().

One of the first lines of this method clears the scrollinfo structure that is passed as argument and that holds the information to be set via SetScrollInfo.

-->    ::memset( &_scroll_info, 0, sizeof(SCROLLINFO) );

This is not correct I think.





       

We agree about the bug in the NCSB_SetScrollInfoWindow() method. The ::memset( &_scroll_info, 0, sizeof(SCROLLINFO) ); line of code should be commented in it.

You can get the track position from the CExtScrollBar windows via invoking the NCSB_GetScrollInfoBar() method in your CExtNCSB-based class.

I found another bug.

 

When I set the scrollposition from within the WM_VSCROLL handler while still pressing the down scrollbutton with the mouse, the CExtScrollbar is not updated to reflect the new position. It is only updated after I release the mouse button.

The CExtScrollBar should be synchronized after each call to the control’s SetScrollInfo() and related functions.

 

 

I am under the impression the class CExtCustomizeSite is not created with the underlying theme style (see for example the project DRAWCLI with any of the Office 2007 - 2010 themes). Is there something special I need to do or is this an implemetation oversight?

Similarly, I am unable to generate scrollbars in CExtPageNavigatorWnd that are in sync with the theme ( again if that theme is Office 2007 - 2010 based). The example PageNavigator bundled with Prof-UIS has scrollbars only for the tree-based pages and even those do not follow the overall theme. Is there a (simple) way to generate correctly those scrollbars for any type of page?

Thank you very much for your help,

Bogdan

 

 

The Customize dialog is classically Windows-themed. But we can make it Prof-UIS themed and even resizable.

The page navigator control is a compound window container. It does not have scroll bars. Any scrollbars you can see inside the page navigator are really scroll bars of some windows inserted into page navigator. If you have the CTreeCtrl window and you want to make it using themed scroll bars, then you should use the CExtNCSB < CTreeCtrl > template based class type.

To reproduce this bug I use MDI_DynamicBars-sud.exe sample from Prof-UIS 2.89 suit.

All steps illustrated by correspondent figure.

Follow the next step.

1. Docking Dynamic Bar 1 to Dynamic Bar 0 – fig.1

2. Hide Dynamic Bar 0 by clicking on close button.

     The resulting bar has not button for switching bar state – fig. 2

     and has strange popup menu – fig.3

To reproduce this bug I use MDI_DynamicBars-sud.exe sample from Prof-UIS 2.8.9 suit.

All steps illustrated by correspondent figure.

1. After last step in Docking  BUG -2 drag Docking Bar using the gray region – fig.1

    After this the unknown gray window appears – fig.2 and fig.3

To reproduce this bug I use MDI_DynamicBars-sud.exe sample from Prof-UIS 2.89 suit.

Follow the next step.

Switching Dynamic Bar 0 state from Docking to Tabbed and then backward to Docking state.

In results the number of  USER Objects, GDI Objects and Handlers will increase.

The number of handles are increased only once. These handles are cached in the paint manager.

To reproduce this bug I use MDI_DynamicBars-sud.exe sample from Prof-UIS 2.89 suit.

All steps illustrated by correspondent figure.

Follow the next step.

1. Docking Dynamic Bar 1 to Dynamic Bar 0 – fig.1

2. Change Dynamic Bar 0 mode to the Tabbed State.

     This is the first bug  - Docking Dynamic Bar 1 bar has not button for switching bar state – fig.2

     Also it has incorrect popup menu (not shown).

3. Hide Dynamic Bar 1 by clicking on close button – fig.3.

4.  Change Dynamic Bar 0 mode to the Docking State.

     In result the bar has incorrect view.   

     Also it has not button for switching bar state – fig. 4

     and strange popup menu – fig.5

To reproduce this bug I use MDI_DynamicBars-sud.exe sample from Prof-UIS 2.8.9 suit.

All steps illustrated by correspondent figure.

Follow the next step.

1. Set all dynamic bars to docking mode and then hide them – fig.1

2. Unhide to bars using “Dynamic Resizable Bars” menu item – fig.2

3. After docking Dynamic Bar 1 Dynamic Bar 0 we will have the first surprise:

Resulting bar has the strange view – fig.3

But this is not the all surprises.

4. Hide this bar by clicking on close button – fig. 4

5. After that unhide Dynamic Bar 0 using “Dynamic Resizable Bars” menu item.

We will see that now bar has not button for switching bar state – fig. 5

And also the bar has strange popup menu – fig.6

Dear Tech-support,

 

I’m calling an exe made using your Prof-UI 2.89 and with the CExtPaintManagerOffice2007_R3_Obsidian theme from an application that is a standard Win32 app using CreateProcess.

 

Once this exe is open, if I create any dialog inside the original Win32 app, the background of such dialog is according to obsidian theme as well.

 

Is it possible to avoid such behavior. Do I miss something inside the Prof-UI application ?

 

Thanks in advance for your help.

 

 Best regards

 

Laura

Please try setting a breakpoint in the CExtResizableDialog::PreSubclassWindow() method and let us know whether it’s invoked before the last non-Prof-UIS dialog with themed by Prof-UIS background appeared on the screen? If yes, then please provide us with the Call Stack listing.

Hi!

How do I hide the File menu in a Ribbon Bar application? I can remove the menu by not creating a CExtRibbonNodeFile object but I can’t seem to get rid of the button.

We are sorry for delay with this reply. Yes, of course, you can simply not create the ribbon file button. The FormulaGrid sample application shows how to do that.

Dear Support,

I have 2 control-bars - one is in docked in auto-hide to one edge of the main-frame, and the second is hidden.

I now what to show the hidden control-bar, so I show it, and I want it to be displayed next to the cursor, so I call FloatControlBar. The minute I call this function my application crashes, at this location:

 

bool CExtBarNcAreaButton::IsBarAutoHideMode(
    bool * p_bDisplayed, // = NULL
    bool * p_bActive // = NULL
    ) const
{
    ASSERT_VALID( this );
    if( p_bDisplayed != NULL )
        *p_bDisplayed = false;
    if( p_bActive != NULL )
        *p_bActive = false;
bool bAutohide = m_pBar->AutoHideModeGet();
    if( !bAutohide )
        return false;
    if( p_bDisplayed != NULL || p_bActive != NULL )
    {
        ASSERT_VALID( m_pBar->m_pDockBar );
        ASSERT_KINDOF( CExtDockBar, m_pBar->m_pDockBar );
...

And I see that m_pBar->m_pDockBar is of type CDockBar and not CExtDockBar

What is the problem? How to fix this? Is this a bug?

Below is the call-stack.

Thanks!

Ron.

 

 

	 ntdll.dll!7c90120e()     
	 [Frames below may be incorrect and/or missing, no symbols loaded for ntdll.dll]    
	 msvcr80d.dll!_CrtDbgBreak()  Line 89    C
	 msvcr80d.dll!_VCrtDbgReportA(int nRptType=2, const char * szFile=0x01f56550, int nLine=13466, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x00127b58)  Line 290    C
	 msvcr80d.dll!_CrtDbgReportV(int nRptType=2, const char * szFile=0x01f56550, int nLine=13466, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x00127b58)  Line 300 + 0x1d bytes    C
	 msvcr80d.dll!_CrtDbgReport(int nRptType=2, const char * szFile=0x01f56550, int nLine=13466, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...)  Line 317 + 0x1d bytes    C
	 mfc80d.dll!AfxAssertFailedLine(const char * lpszFileName=0x01f56550, int nLine=13466)  Line 25 + 0x14 bytes    C++
>    ProfUIS287md.dll!CExtBarNcAreaButton::IsBarAutoHideMode(bool * p_bDisplayed=0x00127bd3, bool * p_bActive=0x00000000)  Line 13466 + 0x2a bytes    C++
	 ProfUIS287md.dll!CExtBarNcAreaButton::OnQueryVisibility()  Line 13816 + 0xe bytes    C++
	 ProfUIS287md.dll!CExtBarNcAreaButtonClose::OnQueryVisibility()  Line 14553 + 0x8 bytes    C++
	 ProfUIS287md.dll!CExtControlBar::OnNcAreaButtonsReposition()  Line 13368 + 0xf bytes    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::OnTimer(unsigned int nIDEvent=1)  Line 1784 + 0x12 bytes    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=275, unsigned int wParam=1, long lParam=0, long * pResult=0x00127ecc)  Line 2032    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=275, unsigned int wParam=1, long lParam=0)  Line 1741 + 0x20 bytes    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::WindowProc(unsigned int message=275, unsigned int wParam=1, long lParam=0)  Line 2364 + 0x14 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x39d71560, HWND__ * hWnd=0x001521e0, unsigned int nMsg=275, unsigned int wParam=1, long lParam=0)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x001521e0, unsigned int nMsg=275, unsigned int wParam=1, long lParam=0)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x001521e0, unsigned int nMsg=275, unsigned int wParam=1, long lParam=0)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 user32.dll!7e418816()     
	 ntdll.dll!7c90e473()     
	 user32.dll!7e4189cd()     
	 user32.dll!7e4274b2()     
	 user32.dll!7e418a10()     
	 user32.dll!7e427721()     
	 user32.dll!7e4249c4()     
	 user32.dll!7e43a956()     
	 msvcr80d.dll!_output_s_l(_iobuf * stream=0x000b18b6, const char * format=0x00194200, localeinfo_struct * plocinfo=0x00196ad0, char * argptr=0x00012012)  Line 1166 + 0x17 bytes    C++
	 user32.dll!7e4664a2()     
	 user32.dll!7e450877()     
	 user32.dll!7e45082f()     
	 msvcr80d.dll!__crtMessageBoxA(const char * lpText=0x001287bc, const char * lpCaption=0x102d315c, unsigned int uType=73746)  Line 168 + 0x13 bytes    C
	 msvcr80d.dll!__crtMessageWindowA(int nRptType=2, const char * szFile=0x01f56550, const char * szLine=0x0012a830, const char * szModule=0x00000000, const char * szUserMessage=0x00129830)  Line 420 + 0x16 bytes    C
	 msvcr80d.dll!_VCrtDbgReportA(int nRptType=2, const char * szFile=0x01f56550, int nLine=13466, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x0012e8c4)  Line 420 + 0x28 bytes    C
	 msvcr80d.dll!_CrtDbgReportV(int nRptType=2, const char * szFile=0x01f56550, int nLine=13466, const char * szModule=0x00000000, const char * szFormat=0x00000000, char * arglist=0x0012e8c4)  Line 300 + 0x1d bytes    C
	 msvcr80d.dll!_CrtDbgReport(int nRptType=2, const char * szFile=0x01f56550, int nLine=13466, const char * szModule=0x00000000, const char * szFormat=0x00000000, ...)  Line 317 + 0x1d bytes    C
	 mfc80d.dll!AfxAssertFailedLine(const char * lpszFileName=0x01f56550, int nLine=13466)  Line 25 + 0x14 bytes    C++
	 ProfUIS287md.dll!CExtBarNcAreaButton::IsBarAutoHideMode(bool * p_bDisplayed=0x0012e93f, bool * p_bActive=0x00000000)  Line 13466 + 0x2a bytes    C++
	 ProfUIS287md.dll!CExtBarNcAreaButton::OnQueryVisibility()  Line 13816 + 0xe bytes    C++
	 ProfUIS287md.dll!CExtBarNcAreaButtonClose::OnQueryVisibility()  Line 14553 + 0x8 bytes    C++
	 ProfUIS287md.dll!CExtControlBar::OnNcAreaButtonsReposition()  Line 13368 + 0xf bytes    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::OnSize(unsigned int nType=0, int cx=0, int cy=0)  Line 1598 + 0x12 bytes    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=5, unsigned int wParam=0, long lParam=0, long * pResult=0x0012ebd4)  Line 2052    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=5, unsigned int wParam=0, long lParam=0)  Line 1741 + 0x20 bytes    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::WindowProc(unsigned int message=5, unsigned int wParam=0, long lParam=0)  Line 2364 + 0x14 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x39d71560, HWND__ * hWnd=0x001521e0, unsigned int nMsg=5, unsigned int wParam=0, long lParam=0)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x001521e0, unsigned int nMsg=5, unsigned int wParam=0, long lParam=0)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x001521e0, unsigned int nMsg=5, unsigned int wParam=0, long lParam=0)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 user32.dll!7e418816()     
	 user32.dll!7e428ea0()     
	 user32.dll!7e428eec()     
	 ntdll.dll!7c90e473()     
	 user32.dll!7e4194be()     
	 user32.dll!7e42f5c6()     
	 user32.dll!7e42c228()     
	 uxtheme.dll!5ad71af6()     
	 user32.dll!7e42c17e()     
	 uxtheme.dll!5ad8c2b1()     
	 user32.dll!7e42f15c()     
	 user32.dll!7e42c17e()     
	 user32.dll!7e418734()     
	 user32.dll!7e42c17e()     
	 user32.dll!7e42c17e()     
	 user32.dll!7e418816()     
	 user32.dll!7e42c17e()     
	 user32.dll!7e42c17e()     
	 user32.dll!7e42a013()     
	 user32.dll!7e42c17e()     
	 user32.dll!7e42a998()     
	 user32.dll!7e42c17e()     
	 mfc80d.dll!CWnd::DefWindowProcA(unsigned int nMsg=71, unsigned int wParam=0, long lParam=1242224)  Line 1029 + 0x20 bytes    C++
	 mfc80d.dll!CWnd::Default()  Line 274    C++
	 mfc80d.dll!CWnd::OnWindowPosChanged(tagWINDOWPOS * __formal=0x0012f470)  Line 422 + 0xf bytes    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::OnWindowPosChanged(tagWINDOWPOS * lpwndpos=0x0012f470)  Line 1607    C++
	 mfc80d.dll!CWnd::OnWndMsg(unsigned int message=71, unsigned int wParam=0, long lParam=1242224, long * pResult=0x0012f240)  Line 2158    C++
	 mfc80d.dll!CWnd::WindowProc(unsigned int message=71, unsigned int wParam=0, long lParam=1242224)  Line 1741 + 0x20 bytes    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::WindowProc(unsigned int message=71, unsigned int wParam=0, long lParam=1242224)  Line 2364 + 0x14 bytes    C++
	 mfc80d.dll!AfxCallWndProc(CWnd * pWnd=0x39d71560, HWND__ * hWnd=0x001521e0, unsigned int nMsg=71, unsigned int wParam=0, long lParam=1242224)  Line 240 + 0x1c bytes    C++
	 mfc80d.dll!AfxWndProc(HWND__ * hWnd=0x001521e0, unsigned int nMsg=71, unsigned int wParam=0, long lParam=1242224)  Line 389    C++
	 mfc80d.dll!AfxWndProcBase(HWND__ * hWnd=0x001521e0, unsigned int nMsg=71, unsigned int wParam=0, long lParam=1242224)  Line 411 + 0x15 bytes    C++
	 user32.dll!7e418734()     
	 user32.dll!7e42bdf1()     
	 user32.dll!7e428ea0()     
	 user32.dll!7e42be3b()     
	 ntdll.dll!7c90e473()     
	 user32.dll!7e4299ff()     
	 mfc80d.dll!CWnd::SetWindowPos(const CWnd * pWndInsertAfter=0x00000000, int x=0, int y=0, int cx=6, int cy=23, unsigned int nFlags=22)  Line 322 + 0x2a bytes    C++
	 mfc80d.dll!CFrameWnd::RecalcLayout(int bNotify=1)  Line 2032    C++
	 mfc80d.dll!CMiniDockFrameWnd::RecalcLayout(int bNotify=1)  Line 830    C++
	 ProfUIS287md.dll!CExtMiniDockFrameWnd::RecalcLayout(int bNotify=1)  Line 2408    C++
	 ProfUIS287md.dll!CExtControlBar::FloatControlBar(CPoint ptFloat={...}, unsigned long dwStyle=8196)  Line 19632 + 0x14 bytes    C++
 
 

 

Thank you for reporting this issue. Please update the source code for the following method:

bool CExtBarNcAreaButton::IsBarAutoHideMode(
            bool * p_bDisplayed, // = NULL
            bool * p_bActive // = NULL
            ) const
{
            ASSERT_VALID( this );
            if( p_bDisplayed != NULL )
                        *p_bDisplayed = false;
            if( p_bActive != NULL )
                        *p_bActive = false;
bool bAutohide = m_pBar->AutoHideModeGet();
            if( ! bAutohide )
                        return false;
            if( p_bDisplayed != NULL || p_bActive != NULL )
            {
                        if( m_pBar->m_pDockBar == NULL )
                                    return false;
                        ASSERT_VALID( m_pBar->m_pDockBar );
                        if( ! m_pBar->m_pDockBar->IsKindOf( RUNTIME_CLASS(CExtDockBar) ) )
                                    return false;
                        CExtDynAutoHideArea * pWndAutoHideArea =
                                    ((CExtDockBar*)m_pBar->m_pDockBar)->_GetAutoHideArea();
                        ASSERT_VALID( pWndAutoHideArea );
                        if( pWndAutoHideArea->m_pWndSlider != NULL )
                        {
                                    ASSERT_VALID( pWndAutoHideArea->m_pWndSlider );
                                    if( pWndAutoHideArea->m_pWndSlider->_GetBar() == m_pBar )
                                    {
                                                if( p_bDisplayed != NULL )
                                                            *p_bDisplayed = true;
                                                if( p_bActive != NULL )
                                                            *p_bActive = pWndAutoHideArea->m_pWndSlider->m_bWndActive;
                                    }
                        }
            }
            return true;
}

Dear Support,

It did prevent the crash at the above location, but now it crashes in a different place:

void CFrameWnd::ShowControlBar(CControlBar* pBar, BOOL bShow, BOOL bDelay)
{
    ENSURE_VALID(pBar);
    CFrameWnd* pParentFrame = pBar->GetDockingFrame();
    ASSERT(pParentFrame->GetTopLevelParent() == GetTopLevelParent());
        // parent frame of bar must be related

    if (bDelay)
    {
        pBar->DelayShow(bShow);
        pParentFrame->DelayRecalcLayout();
    }
    else
    {
        pBar->SetWindowPos(NULL, 0, 0, 0, 0,
            SWP_NOZORDER|SWP_NOMOVE|SWP_NOSIZE|SWP_NOACTIVATE|
            (bShow ? SWP_SHOWWINDOW : SWP_HIDEWINDOW));
        // call DelayShow to clear any contradictory DelayShow
        pBar->DelayShow(bShow);
        if (bShow || !pBar->IsFloating())
            pParentFrame->RecalcLayout(FALSE);
    }

    // show or hide the floating frame as appropriate
    if (pBar->IsFloating())
    {
        int nVisCount = pBar->m_pDockBar != NULL ?
            pBar->m_pDockBar->GetDockedVisibleCount() : bShow ? 1 : 0;
        if (nVisCount == 1 && bShow)
        {
            pParentFrame->m_nShowDelay = -1;
            if (bDelay)
            {
                pParentFrame->m_nShowDelay = SW_SHOWNA;
                pParentFrame->RecalcLayout(FALSE);
            }
            else
                pParentFrame->ShowWindow(SW_SHOWNA);
        }
        else if (nVisCount == 0)
        {
            ASSERT(!bShow);  <<<<<< THIS IS WHERE IT ASSERTS
            pParentFrame->m_nShowDelay = -1;
            if (bDelay)
                pParentFrame->m_nShowDelay = SW_HIDE;
            else
                pParentFrame->ShowWindow(SW_HIDE);
        }
        else if (!bDelay)
        {
            pParentFrame->RecalcLayout(FALSE);
        }
    }
}

This happens only if I have a control-bar in the auto-hide mode, otherwise it does not asserts there.

Thanks,

Ron.

Dear Support,

I added to my grid initialization this line:

    NoHideSelectionSet(true, false);

I clicked on a cell, which gives it focus, and then I click on another control, the blue-background of the cell did not remain

Please fix.

Thanks,

Ron.

We cannot confirm this. The un-focused grid control should display selected cells with a dark gray background. If you need a blue background, then please override the CExtScrollItemWnd::OnSiwQueryFocusedControlState() virtual method in your grid class and simply return true from it.

Dear Support,

Can you please tell me where I can find a sample of this feature working? I could not make it work...

Thanks,

Ron.

Hi.

I have a problem. My application (using Prof-UIS V2.88 MBCS) sometimes crashes on exit. Unhandled exception is received in ExtComboBox.cpp line 265.

The call stack is below. Is there a fix for this?

ProfUIS288md.dll!CExtComboBoxPopupListBox::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0)  Line 265 + 0x26 bytes C++

ProfUIS288md.dll!CExtNCSB_Impl<CExtComboBoxPopupListBox>::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0)  Line 1168 + 0x14 bytes C++

mfc90d.dll!AfxCallWndProc(CWnd * pWnd=0x036647c8, HWND__ * hWnd=0x010f0e0a, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 240 + 0x1c bytes C++

mfc90d.dll!AfxWndProc(HWND__ * hWnd=0x010f0e0a, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 403 C++

mfc90d.dll!AfxWndProcBase(HWND__ * hWnd=0x010f0e0a, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 441 + 0x15 bytes C++

user32.dll!7e368734()  

[Frames below may be incorrect and/or missing, no symbols loaded for user32.dll] 

user32.dll!7e37bdf1()  

user32.dll!7e38ebc9()  

user32.dll!7e38eb8f()  

msvcr90d.dll!1023d496()  

user32.dll!7e368734()  

user32.dll!7e368816()  

user32.dll!7e37a013()  

user32.dll!7e37a998()  

mfc90d.dll!CWnd::DefWindowProcA(unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 1043 + 0x20 bytes C++

mfc90d.dll!CWnd::Default()  Line 274 C++

mfc90d.dll!CWnd::OnNcDestroy()  Line 853 C++

OptionTrader.exe!CMyExtComboBox::OnNcDestroy()  Line 95 C++

mfc90d.dll!CWnd::OnWndMsg(unsigned int message=130, unsigned int wParam=0, long lParam=0, long * pResult=0x0012d868)  Line 2042 C++

mfc90d.dll!CWnd::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0)  Line 1755 + 0x20 bytes C++

ProfUIS288md.dll!CExtComboBoxBase::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0)  Line 2838 C++

ProfUIS288md.dll!CExtComboBox::WindowProc(unsigned int message=130, unsigned int wParam=0, long lParam=0)  Line 4179 C++

mfc90d.dll!AfxCallWndProc(CWnd * pWnd=0x0361b0b8, HWND__ * hWnd=0x00b00e84, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 240 + 0x1c bytes C++

mfc90d.dll!AfxWndProc(HWND__ * hWnd=0x00b00e84, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 403 C++

mfc90d.dll!AfxWndProcBase(HWND__ * hWnd=0x00b00e84, unsigned int nMsg=130, unsigned int wParam=0, long lParam=0)  Line 441 + 0x15 bytes C++

user32.dll!7e368734()  

user32.dll!7e37bdf1()  

user32.dll!7e378ea0()  

user32.dll!7e37b16f()  

ntdll.dll!7c90e473()  

user32.dll!7e37b1a8()  

mfc90d.dll!CWnd::DestroyWindow()  Line 1007 + 0xd bytes C++

90909090() 

I have a CExtTreeCtrl with some checkbox items and need to do something when user clicks(Check/Uncheck) on the checkbox.

How do I get the message? Could you show me some sample code, Thanks

 

Hi,

Normally Prof-UIS are very good at responding here, but I now have four open items with no reply since between March 23 and April 15.  Three of those have 1 or 2 follow-up nudges, but I’ve had no response to anything since April 15.  The design of this forum makes it very hard to spot where a new post is within a discussion, so here are links to the as-yet-unanswered topics, with brief comment on each:

www.prof-uis.com/prof-uis/tech-support/support-forum/bad-ribbon-bar-stuff-that-doesnt-match-ms-word-67145.aspx#67387

That discussion was almost sorted, and just waiting on what I think should be a simple answer, and probably a simple fix in the Prof-UIS code as I described.  Not vital to us, but would be nice, and should be very simple.

www.prof-uis.com/prof-uis/tech-support/support-forum/ribbon-group-tooltips-67116.aspx#67336

I expect this probably isn’t too difficult to fix?

www.prof-uis.com/prof-uis/tech-support/support-forum/changing-mdi-tab-label-forced-redraw-of-view-67350.aspx#67361

Redrawing EVERY view when an MDI tab is clicked is a pretty bad thing, especially if it’s the current tab.  If it’s not the current tab, then only one view moved to the top of the Z order and should be repainted.  There is no RecalcLayout required.  Same when programmatically changing the doc title.  This is more important to us than the previous two, but maybe more involved?

www.prof-uis.com/prof-uis/tech-support/support-forum/changing-ribbon-bar-height-67068.aspx#67168

This one is most important to us, but also the most involved.  The ability to change the ribbon bar height is beyond Microsoft’s spec, but would be a great improvement.  Although it’s a significant change, it seems there are only a few things making it impractical at the moment, as discussed in my post.  The height can already be set, but a few things don’t adjust to the change properly.  We’d love to see those few things dealt with.

Thanks,

Rob.

It’s not a problem to increase the maximal informativeness level for ribbon elements. Please fine the following line of code in the .../Prof-UIS/Include/ExtToolControlBar.cpp file:

   #define __EXT_RIBBON_ILE_MAX                                                         10

And replace it with the following:

   #define __EXT_RIBBON_ILE_MAX                                                         30

This is the largest possible effective informativeness value and it does not break compatibility with older Prof-UIS versions.

The second question looks like resolved because you can choose between old and new caption trimming mode for ribbon groups. This can be done with overriding the CExtRibbonPage::OnRibbonQueryGroupCaptionTextCompletelyVisible() virtual method. You can also optionally show tooltips over trimmed button group captions and this is controlled by the CExtRibbonPage::OnRibbonQueryGroupCaptionTextWithToolTip() virtual method.

This third problem is only partially related to MDI tabs. The standard Windows MDI interface became half-broken in Windows XP and it’s in the same state in the later Windows versions. The maximized MDI child frames become quickly restored and maximized again when you switching the active MDI child frame. This "improvement" was introduced in Windows XP. As you probably know, Microsoft does not use the MDI interface in its latest products. The Visual Studio .NET and later versions does not use it. The Office 2007/2010 too. We don’t know how the design of the latest Microsoft apps is related to the broken MDI interface, but we had to fix the MDI interface flicker issue in Prof-UIS. We do tiling and cascading manually. We use the screen photo trick when switching the active MDI child frame windows and that’s the source of additional repainting messages. Prof-UIS creates non-painted window over the MDI interface when you switching the active MDI child frame window. This window contains image of the desktop surface under it. The same screen photo approach is used when creating or destroying MDI child fames because the standard MDI interface can also produce the same surprises in these cases.

The last question is the most interesting for us. We have the two big conflicts of the ribbon bar design with the custom height ribbon tab pages: the big buttons with the 32x32 icon and 1..2 lines of text at the bottom and the ribbon galleries. These buttons are incompatible with the ribbon bar containing less than 3 rows of smaller buttons in the ribbon tab pages. The ribbon galleries also cannot be compressed to the less height.

Re first question: looks good, 30 is probably sufficient.  Are you making this change in the main distribution?  That’s the main thing.  I don’t want to have to change it with every new version.

Re second question: no, it isn’t resolved.  Please read my other post about it.  I already override that function, which allows ribbon group labels to be truncated EXCEPT when they collapse to a single button.  Then, despite the system trying to save space, they suddenly get bigger as the full text re-appears.  What I’m asking for is that the group label should also be truncated when collapsed to a single button.

Re third question: thanks for the explanation.  Sounds like you won’t be changing it?  It seems at least that when clicking on the current tag that all messages should be avoided as there’s nothing to do.  In particular, if you click on the X to close the current tab, it first insists on redrawing everything in ALL the views.  I’m sure that can be avoided by catching the click and redirecting it as necessary.

Re fourth question: yes, it is the most interesting :-)  We don’t use ribbon galleries at all, so don’t care whether they work, although obviously you will want a generic solution.  Why not just collapse them to a single button as already happens when they get too small.  You can improve that later if necessary, but if the items in the gallery are too tall for the ribbon bar, then there’s probably no choice.

As for 32x32 icons with 1..2 lines ot text below them, I would just say that you can’t have those in a ribbon bar that’s too short.  They should auto-collapse to 16x16 buttons.  This is what we expect, that on a short ribbon bar, no 32x32 icons will appear, rather 1 or 2 rows of 16x16 icons.  Surely that’s what anyone would expect in this situation?

The other thing you need to handle is when ribbon groups collapse into a single button.  Here it insists on using a 32x32 icon.  It needs to use 16x16 instead.

Finally, for our app, we have ribbon bar text fields which are taller than buttons, and will need to know how to change their height.  How do we do that?

Thanks,

Rob.

1) Yes, 30 is permanent change. Its already inside Prof-UIS 2.90. You can drop us an e-mail to the support mail box and we will provide you with the download information.

2)The ribbon button, including group buttons, expect to have text containing one or two lines of text only. The expanded group button converts the double line text into single line text. We made the group buttons using ellipsis text effect in the expanded mode. That was your feature request. We can make the same in the collapsed mode. But how should we apply the ellipsis effect in the double line text mode? Should we make ellipsis in both lines? Show we convert the group caption text into single line and then draw it with ellipsis?

3) Needs additional debugging. We think we will be able to remove repainting.

4) We can do this. The ribbon bar/ribbon page should understand and use the new property: the count of rows with the standard small/middle ribbon buttons. Currently this is 3 rows and the problem, that this is very hard coded in all the paint managers and we had carefully debug variable count of rows in Windows XP and later versions using several different DPI screen settings.

5) So, you don’t need 32x32 icons at all in the desired condensed layout of the ribbon bar? This makes the task much easier.

6) We can do this. But 16x16 icons in the collapsed ribbon group button may look like very small relatively to the skin bitmaps of the Office 2007 blue/silver/black themes.

7) The text and combo fields are the CExtBarTextFieldButton buttons. Their size is computed by the CExtBarTextFieldButton::CalculateLayout() virtual method which uses the CExtBarTextFieldButton::OnInplaceControlCalcMarginSizes() virtual method for computing outer margins. By default, the CExtBarTextFieldButton::OnInplaceControlCalcMarginSizes() method returns the CRect(2,2,2,2) margins in pixels. You can override any of these methods to make the text/combo fields smaller.

Sorry, it’s been my turn to be silent this time!  Here are my thoughts.

1) Great, thanks.

2) The same in collapsed mode would be great.  I’d suggest using ellipsis on both lines, since at least there’s a bit more info then.  The important thing is that my collapsed button isn’t larger than the group when it isn’t collapsed.

3) Thanks.  There are a couple of cases:

    a) Clicking the X should close the tab without redrawing any windows other than those which are exposed by the operation.

    b) Whether or not the child windows are maximised within the frame, all views are redrawn whenever a view is made current.  In this case only the new current view has become more exposed, and it should be the only one redrawn.

4) OK

5) If the ribbon bar is resized too small for a 32x32 icon, then I think the only thing one can expect is that smaller icons will be used instead.  This should probably override other rules too.  Eg, if the programmer has forced an icon to always be large, by removing the small rules, it should still go small if there’s simply not enough height in the ribbon bar for it.

6) That’s fine.  Has to be done though, or the collapsed group button just gets truncated off the bottom.

7) I need to look into this sometime.  I already have those functions overridden and it’s not changing the size of the buttons no matter what I set things to.  I think something else is at play.

So any update on making the ribbon bar height resize nicely?  This is still the thing of most interest to us.  Being able to dock the ribbon bar vertically would be fantastic too, but I’m guessing that won’t happen any time soon.

Other features that we would really find useful are the ability for the user to drag and drop ribbon tabs and groups.  We’ve seen that competitors to our software now have this functionality.  You can even drag a ribbon group out of the ribbon bar, leaving it in a floating window of its own.  I know MS doesn’t do it, and I don’t think BCG or CodeJock support it either, but it would be great for increased usability.  Have you thought about this?

Thanks,

Rob.

Hello,

I’m using derived from TabPages classes (one from CExtTabPageContainerWhidbeyWnd, the other from CExtTabWnd) and was wanting to make it possible to reorder them by drag and drop.

What would be the cleanest/easiest approach to achieve this ?