Professional UI Solutions
Site Map   /  Register
 
 

Forum

Please Log In to post a new message or reply to an existing one. If you are not registered, please register.

NOTE: Some forums may be read-only if you are not currently subscribed to our technical support services.

Forums » Prof-UIS Tech Support » No response from tech support for some weeks Collapse All
Subject Author Date
Ian McIntosh Aug 28, 2007 - 8:44 AM

Hi,

I have at least 2 threads that I have not had a response on for several weeks, the threads are called:

"autohide temporarily stops working"
"minimize / maximize issue"

Please can you let me know what is happening.

I have also noticed with the minimize/maximize issue if I use PreCreateWindow() to set the WS_MAXIMIZE style, the app is drawn incorrectly. If i call ShowWindow(SW_SHOWMAXIMIZED) this also gives an incorrect result. Do you have a work around that will allow me to programatically maximize my app?

Technical Support Aug 30, 2007 - 11:16 AM

We are currently recoding the DWM integration (Desktop Window Manager on Windows Vista which implements glass effects for desktop’s child windows) of the CExtRibbonBar control. The height of the caption when the window is maximized on Windows Vista is less than that when the window is restored. This is not a problem for classic desktop windows. But desktop window with integrated ribbon bar should have a greater caption height. We are working on this problem now.

The auto-hidden bar behavior is mostly similar to dockable panes in Visual Studio .NET and Visual Studio 2005. If you close all the windows in Visual Studio, show an auto-hidden bar, set focus to some window inside this control bar and click on empty MDI/tabbed area, then the control bar will not get hidden back. The temporarily displayed auto-hidden bar should not hide itself in two cases: when the mouse is over it and when some window inside it is focused and, as a result, the control bar is active. Some windows like the MDI client area, ribbon bar, menu bar, toolbars, status bar and others never request focus on mouse clicks. That is why the displayed auto-hidden control bar does not go back to its hidden state: there are no windows which "want" to get focus. The editor windows inside a toolbar or the ribbon bar requests focus on click and displays the caret. This makes window inside the control bar unfocused and deactivates the control bar.

We confirm the other problem with auto-hide tabs near the frame border: when the edit control is focused inside a toolbar or the ribbon bar, then moving the mouse pointer over the auto-hide tab item does not lead to the the auto-hidden control bar rolls out. But clicking the tab item in this case always displays the control bar. Both mouse hover and click should display this bar. We will fix this problem as soon as possible and notify you about that.

Technical Support Aug 28, 2007 - 11:54 AM

We are sorry for this delay. We confirm that this problem exists, when the main window is incorrectly shifted a couple of pixels upwards under the following conditions:

1) the application has the ribbon-based interface
2) the main window is maximized

We are refactoring the ribbon code so this bug will be fixed in a new release in September.

As for the problem with the autohide, we cannot yet completely confirm it. We created a control bar with a dialog and a button. We added it to the SDIDOCVIEW sample, tried to reproduce the bug and failed. Please note that when you click the button, the control’s bar caption gets highlighted and in order to hide the control bar, you should click on somewhere outside the control bar. We also added this control bar to the RibbonBar app and noticed that the problem does not occur if you click a control that takes selection (show the control bar, click the button and select a control in the ribbon, e.g. Style 1, Style 2, etc.). Anyway we will look into it once more and let you know the results tomorrow.