Forum

Good day.
Could anyone be so kind to help in the problem with CExtScrollBar.
The problem is a "wrong" behaviour of CExtScrollBar. The sample
application "AviFrames" have a class CAviView that is a child of
CExtScrollWnd. Here i should say that in my humble opinion class
CExtScrollWnd should own CExtScrollBar as scroll bars, but i can be
mistaken. That is what i am doing to add "theme-ready"(CExtScrollBar)
scrollbars:

First, i add members in class declaration

    ...
    CExtScrollBar m_wndScrollBarH, m_wndScrollBarV;
    ...

and method

    ...
    virtual CScrollBar * GetScrollBarCtrl(int nBar) const;
    ...

Second, realisation in class definition


    ...
    CScrollBar * CAviView::GetScrollBarCtrl(int nBar) const
    {
        ASSERT_VALID( this );
        if( m_hWnd == NULL || (! ::IsWindow(m_hWnd) ) )
            return NULL;
        ASSERT( nBar == SB_HORZ || nBar == SB_VERT );
        if( nBar == SB_HORZ )
        {
            if( m_wndScrollBarH.GetSafeHwnd() != NULL )
                return ( const_cast < CExtScrollBar * > ( &m_wndScrollBarH ) );
        }
        else
        {
            if( m_wndScrollBarV.GetSafeHwnd() != NULL )
                return ( const_cast < CExtScrollBar * > ( &m_wndScrollBarV ) );
        }
        return NULL;
    }
    ...

Last step is adding creation of scroll bars in the OnCreate() method

    ...
    int CAviView::OnCreate(LPCREATESTRUCT lpCreateStruct)
    {
        if( CExtScrollWnd::OnCreate(lpCreateStruct) == -1 )
            return -1;
    
     //////////////////////
        m_wndScrollBarH.m_eSO = CExtScrollBar::__ESO_BOTTOM;
        m_wndScrollBarV.m_eSO = CExtScrollBar::__ESO_RIGHT;
        if( ! m_wndScrollBarV.Create(
            WS_CHILD | WS_VISIBLE | SBS_VERT | SBS_RIGHTALIGN,
            CRect(0,0,0,0),
            this,
            1))
        {
            ASSERT( FALSE );
            return -1;
        }
        if( ! m_wndScrollBarH.Create(
            WS_CHILD | WS_VISIBLE | SBS_HORZ | SBS_BOTTOMALIGN,
            CRect(0,0,0,0),
            this,
            2))
        {
            ASSERT( FALSE );
            return -1;
        }
        m_wndScrollBarH.SyncReservedSpace( &m_wndScrollBarV );
        m_wndScrollBarV.SyncReservedSpace( &m_wndScrollBarH );


        m_bInitComplete = true;
    
        return 0;
    }
    ...


After all new scroll bars are "semiworkable" in contrast to standard scroll bars before modifications.
What is wrong with this code and where is my mistake?

Thanks in advance.

https://supplementlast.com/

I admire your commitment to authenticity and honesty in your writing. It’s truly inspiring.
https://supplementlast.com/

The AviFrames implements scrolling in a special way. The CAviView window hosts the CAviPlayerWnd child window inside and when the user is dragging a scroll box, we make this window occupy the full client area of CAviView. Of course we can fix this issue but in real projects (when the CExtScrollWnd window does not host any child windows inside) scrolling should work without any problem. There are several classes in Prof-UIS like CExtColorPaletteWnd, CExtImageEditWnd, CExtToolBoxWnd and CExtScrollItemWnd (which is the base class for all the grids) which are derived from CExtScrollWnd. They all work fine.

First of all, thanks for quick reply.
Second, and sorry(but i can’t be silent :) ), why the standard scrollbars work in analogous situation? Here i think of scrollbars like buttons on dialog - when i subclass standars button with CExtButton i do not think of handling an additional logic of new button and it is "automagically" works. I will explain what i do. I have a splitter(static) that holds in one of its panes C[Scrolling-capable window] (lets call it CMyScrl) that holds a resizable dialog. In CMyScrl’s method OnSize() i am resizing child dialog to client area if its size is bigger than initial(minimum ideal that given to dialog on designing stage). So the quiestion is how to add "themeable" scrollbars to my CMyScrl? (If in something new the logic is different - exapmles rule). I thought that native to "profuis"-library class CExtScrollWnd uses special scrollbars(for consistency) but unfortunately it doesn’t :(. I tried MFC’s CScrollView but with manipulations to adding CExtScrollBar-scrollbars described above in first message(m_wndScrollBarH, m_wndScrollBarV, GetScrollBarCtrl(), ...) the scrollbars don’t appear at all. So question remains how to replace standard scrollbars with "nice"-looking ones(may be on "AviFrames" example...)?
Also i noticed some issue with "Picture Control" of type "Etched Vert" on my dialog. When dialog is hosted by CExtScrollWnd this control(that anchored as AddAnchor(IDC_CTRL, CPoint(50,0), CPoint(50,100))) sometimes disappears when i enlarge parent window in horizontal direction by small steps(and "show window content while dragging" property of display is on). It happens only with applied theme. If no theme("Native windows XP theme") is applied to application "Picture control" is "drifted" well. No such behaviour is noticed with CScrollView window.
Also one question is how to make icon IDR_MAINFRAME on about dialog be consistent with current theme?

Thank you very much for your help.
We are trying your suit for our needs.

The anchoring mechanism in Prof-UIS is designed for non-scrollable windows only because the window size and the size of scrollable area are independent parameters. So, you should use two windows if you want to have both anchoring and scrolling: an outer scrollable window and an inner resizable dialog with assigned anchors. This is similar to the design of the view window in the AviFrames sample where we had to use both an outer scrollable window and an inner non-scrollable player window because video output directly to the scrollable window is buggy. As for the disappeared etched frame control: please check the Z order of dialog controls - the Z order of the etched frame control should be greater then Z orders of other controls which are "inside" the etched frame. The same rule should be applied for group boxes. Please let us know more details about your last question. We wonder what kind of consistency between icon and theme you mean?

For resizable dialog i uploaded some screenshots:

mmm... part of a message disappears. ) It is certainly daemons. )

before resizing - http://www.flickr.com/photos/86788125@N00/211052827/

after resizing - http://www.flickr.com/photos/86788125@N00/211057278/

For the second link, "etched vert" picture control in most cases disappear at all and appears after minimizing-restoring an application. Here i assume that i do something wrong but as i noted in earlier message this visual behaviour takes place only for CExtScrollWnd as a parent window and theme applied(except for themes "Native Windows XP theme", "Office XP theme" and "Office 2000 theme").

We are currently trying to find a solution to this problem. But you can temporarily handle the WM_HSCROLL and WM_VSCROLL standard Windows messages and invalidate the etched frames:

class CYourScrollableWindow : public CExtScrollWnd
{
protected:
    virtual LRESULT WindowProc( UINT message, WPARAM wParam, LPARAM lParam )
    {
        LRESULT lResult = CExtScrollWnd::WindowProc( message, wParam, lParam );
        if( message == WM_HSCROLL || message == WM_VSCROLL )
            m_wndInnerDialog.m_wndEtchedFrameControl.Invalidate();
        return lResult;
    }
};

Ok. Thanks.
Returning to scrollbars... What is the best(?) and more importantly the easiest way to replace standart scrollbars with yours in, for example, CScrollView derived class?

You should create CExtScrollBar windows inside the CScrollView window and override the CWnd::GetScrollBarCtrl() method in your view class and return the pointers to horizontal or vertical scroll bar windows depending on the method parameters. You can send us your test project if you come across any difficulties.

>You can send us your test project if you come across any difficulties.
I can send simple project. What email address can i use?

For better time spending i sent it to support@prof-uis.com. Sorry if it is a wrong destination.

I probably was "not understandable" with my english but it is not my native language, sorry. Of course i have outer window(or view) with scrolling capabilities that owns resizable dialog as a child window.

Under the term "consistency" i mean that the icon(with transparent background) in dialog "About" is not themeable. In that dialog a static text can be "substituted" with CExtLabel class and will be "consistent" with current theme. As for the icon i probably do not know needed class. It is especially noticeable in "Office 2007 Obsidian theme". All that i said is relates to default "about dialog" created by the wizard. Just generate any application and see the "About"-dialog(with MFC-icon) with different themes applied. I’ve found a place for screenshots. :) http://www.flickr.com/photos/86788125@N00/211029969/ Have i missed something?

Thanks in advance.

Both icon and static text dialog items are variants of the static common control. You can subclass them with CExtLabel.

Ok. What i am doing(for ICON) - in an About-dialog i have a class member

...
CExtLabel m_staticIcon;
...

In CAboutDlg::OnInitDialog() i subclass icon control:

...
m_staticIcon.SubclassDlgItem(IDC_STATIC_ICON, this);
...

And after all icon have its "own" background as i wrote earlier. But after switching to another application hiding About dialog and then returning back to my application the background of the icon is OK(according to current theme).

OK here. I also need to invalidate control after subclassing:

...
m_staticIcon.SubclassDlgItem(IDC_STATIC_ICON, this);
m_staticIcon.Invalidate();
...

Please check whether your dialog window has the WS_CLIPCHILDREN style. This is the single issue which may cause the invalid background of the static icon control. You can run the DRAWCLI sample and invoke the Help | About menu. A dialog with a static icon control will appear on the screen. The icon in this dialog has transparent pixels and everything is painted correctly. The About dialog is implemented in the CExtProfUISAboutDialog class. The icon control is subclassed with the CExtProfUISAboutDialog::m_labelAppIcon class member. We believe the same should be seen in your dialog if it has the WS_CLIPCHILDREN style.