Forum

Dear support,

In the Prof Studio example bundled with the library, whenever one presses the ’Auto Hide’ pin of a docking window (switching thus the mode from docked to sliding) there is a noticeable flicker. I am not quite sure but it looks like the docking control is erased only to be redrawn immediately in the other mode (take for example the Solution Explorer window in ProfStudio.exe: to eliminate other potential causes, make sure there are other docking windows hidden on the same side; expand the Solution Explorer window to the same size, both in the docking mode and in the sliding mode; press several times the pin). Would it be possible for you to advise on eliminating this artifact (eventually by not erasing the old background and simply sending redraw messages to the child windows involved)? This doesn’t happen, for example, in Visual Studio 2008/2005, etc.

Thank you,

Bogdan

Thank you for detailed screen shots. They demonstrate what we do not see and cannot reproduce. Simple apps with 5 resizable bars switch from/to auto-hide mode immediately. ProfStudio sample app shows some lags but not flickering. We checked both Vista/7 DWM mode and XP/2000 classic desktops. Besides, nobody reported similar problems yet.

Thank you for considering this. Here are the steps to reproduce it:

In Visual Studio 2008 with Service Pack 1, select MDIDOCVIEW project in x64/MBCS Debug configuration.
Build and run in the debugger, making Sure Visual Studio and MDIDOCVIEW app do not overlap on the screen.

In the MDIDOCVIEW application, close the view and all the docking bars/toolbars.
From View / Resizable Bars select Editor view.
From View / Resizable Bars select Empty view.
Dock everything to the right side of the application (The Editor view is the rightmost).
Change both views to sliding mode and let them hide.

In Visual Studio, open ExtControlBarTabbedFeatures.cpp.
In the function CExtDynAutoHideSlider::_HookMouseClick(), put a breakpoint in the line
            pLastHitTestB->OnNcAreaClicked( ptWnd ); // line 4567 in 2.92 ammended with one patch
In MDIDOCVIEW, hover over the Empty Tab. That eventually shows the bar.
Press the docking pin of the Empty bar. The program stops in the breakpoint and the view is erased in the application: this is the source of the apparent flickering. This happens due to the line 4566: Activate( pBar, false, false, true );
Press F5 in Visual Studio. Finally, the bar is redrawn.

Erasing the sliding view is unnecessary and creates the apparent flickering.

Can you please confirm you’ve been able to reproduce it. This is consistently reproducible with any MDI app based on your framework.

Thank you,

Bogdan

Thank you for providing us with the important details. Please find the pLastHitTestB->OnNcAreaClicked( ptWnd ); code in the CExtDynAutoHideSlider::_HookMouseClick() method. This is the code invocation meant in your message. There is small if statement just before the pLastHitTestB->OnNcAreaClicked( ptWnd ); code:

            if( pLastHitTestB->OnQueryDeactivateAutohideSlider() )
                Activate( pBar, false, false, true );
            pLastHitTestB->OnNcAreaClicked( ptWnd );

Please modify this if to remove the non-painted flicker effects:

            if( pLastHitTestB->OnQueryDeactivateAutohideSlider() )
            {
                Activate( pBar, false, false, true );
                CExtPaintManager::stat_PassPaintMessages();
            }
            pLastHitTestB->OnNcAreaClicked( ptWnd );

Thank you so much for confirming this.

I’ve probably made a mistake but it doesn’t seem to work for me...By the time the call to Activate() returns, the sliding window is already  gone:

  if( pLastHitTestB->OnQueryDeactivateAutohideSlider() )
    {
	    Activate( pBar, false, false, true );
	    // here, the sliding view is already gone
	    CExtPaintManager::stat_PassPaintMessages();
    }
    pLastHitTestB->OnNcAreaClicked( ptWnd );

This seems to be due to this call: SetWindowPos( NULL, 0,0,0,0,SWP_NOSIZE|SWP_NOMOVE|SWP_NOREPOSITION|SWP_HIDEWINDOW); inside Activate()  (around the line 5669).

If I skip that SetWindowPos() above inside Activate() and I postpone it after pLastHitTestB->OnNcAreaClicked( ptWnd ) inside CExtDynAutoHideSlider::_HookMouseClick() the behavior is much better.  Something like this:

 if( pLastHitTestB->OnQueryDeactivateAutohideSlider() )
  Activate( pBar, false, false, true, true ); // added new arg only to indicate this special case
 pLastHitTestB->OnNcAreaClicked( ptWnd );
 
// (postponed SetWindowPos() postponed from Activate()
if( pLastHitTestB->OnQueryDeactivateAutohideSlider() )
  SetWindowPos(  NULL, 0,0,0,0,  SWP_NOSIZE|SWP_NOMOVE|SWP_NOREPOSITION  |SWP_HIDEWINDOW  );

I do understand that Activate() is called from many places so, I used a supplementary argument while calling it. 

 

The flicker is notably visible because of a large number of bars. ProfStudio creates 42 bars. Prof-UIS does the following when you click the ping button over the bar caption:
1) Hide the bar.
2) Recompute the frame layout.
3) Move bar’s child window into a hidden dynamic auto-hide slider window.
4) Show the auto-hide slider window.
The dynamic auto hide slider window looks like a control bar. But it’s not a bar. There is only one such window inside a frame. It’s re-used for all bars.
The flicker is not really a flicker. It’s time spent for frame layout computation. It’s not visible in a normal application with 5 or 10 bars.

I sent you also an email with the example detailed below.

Dear support,
This is a more detailed explanation of the flickering occurring while switching from docking to sliding mode:

1. Switching from an auto-hide slider to a docking window:

The reason for the apparent flicker has nothing to do with the number of docking windows but rather to an unfortunate side-effect. Consider the MDIDOCView example, where the Empty view is about to be switched from a slider to a docking window:

- first, the auto-hide slider is deactivated by calling CExtDynAutoHideSlider::Activate in CExtDynAutoHideSlider::_HookMouseClick(). Unfortunately the visual side effect is that the slider is hidden, exposing the background
- second, the docking window is drawn in its expected position:

One can reproduce this consistently by setting breakpoints in:
ExtControlBarTabbedFeatures.cpp towards the end of bool CExtDynAutoHideSlider::_HookMouseClick():
            Activate( pBar, false, false, true );
            pLastHitTestB->OnNcAreaClicked( ptWnd );
While I understand the need for deactivating the slider (cancelling timers, resetting the slider’s state, etc.), fact is that the user experience is really bad, since the image flickers.

Can you please reset the slider without hiding it and only redraw the final layout.

2. Switching from a docking window to an auto-hide slider:

Would it be possible for you to keep the slider hidden, immediately after switching from docking to slider (eventually via an option)? This way, there is no need to redraw the auto-hide slider only to have it withdrawn afterwards: after all the user tries to hide that view.
Not calling m_pWndSlider->Activate( pBar, true, false, true ) at the end of CExtDynAutoHideArea::AppendControlBar() seems to do the trick.

I am just trying to help here, so any solution that eliminates the obvious flickering works for me.

Thank you,
Bogdan

Thank you for your prompt response.

I am afraid you are not right.Take another Prof_UIS example - MDIOCView: that one uses only 5 control bars. I closed everything but the Editor and Empty control bars, I hid the Editor on the left side of the main frame and I toggled the sliding pin of the Empty control bar docked also on the left side. The flickering is still noticeable. I have a good notebook (8G Ram, i7 SandyBridge at 2.3 GHz + 1G of memory on the graphics card) so, hardware performance is not an issue.
I also tried Visual Studio 2008 with 43 docking windows opened simultaneously on the same machine and there is no flickering.

Could you please take one more look at this issue: I believe this is a good way to improve your library.

Thank you,

Bogdan