|
|
|
|
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.
Subject |
Author |
Date |
|
Oliver Rau
|
Feb 7, 2008 - 10:52 AM
|
Dear ProfUIS-Team,
there are two issues with respect to the docking/floating behaviour using CExtControlBar , and both can be reproduced with the delivered sample apps (e.g. SDI_DynamicBars, ProfStudio):
1. Suppose having the (WinXP SP2) task bar vertically on the left side of the screen. If loaded out of the box, i.e. without any serialization traces in the registry, double clicking onto the caption bar of a docked window moves it (undocked now) to the screen coordinates (0,0). Unfortunately this behaviour seems to ignore the width of the task bar, i.e. the window is partly covered/hidden by the task bar.
2. Under MS Word 2007 docked windows are showing the following behaviour: Double clicking the caption bar of a docked window undocks it (same as in ProfUIS). Double clicking the caption bar of the undocked window moves it back to the previous docking place (not realized in ProfUIS). It would be nice to have the same behaviour with ProfUIS, too.
Kind regards,
Martin
|
|
Technical Support
|
Feb 18, 2008 - 4:22 AM
|
We have not implemented the double click based toggling of the floating state for resizable control bars because this feature has a conflict in design and even in Visual Studio .NET/2005/2008 it’s not working correctly in 100% of cases. It’s not possible to restore the exact floating state of the control bar inside a complex floating palette if its inner structure was changed since last state toggling.
|
|
Oliver Rau
|
Feb 15, 2008 - 10:33 AM
|
Sorry, under 2. I did not mean MS Word 2007 but MS Visual Studio 2005.
The behaviour here is like follows:
STATE: docked at defined position ACTION: double click bar RESULT: undocked state ACTION: double click bar RESULT: docked state at previous docking position
It would be nice to have the same behaviour with ProfUIS.
Regards,
Martin
|
|
Technical Support
|
Feb 9, 2008 - 1:37 AM
|
You can specify some initial floating positions using the CExtControlBar::SetInitDesiredPosFloating() method. But this does not guarantee the bars will not be located under shell bars like the task bar because shell bars can be re-docked or resized any time. You can also override the CExtControlBar::ToggleDocking() virtual method and make its body empty to disable double click based switching into the floating state. Please also note, the Prof-UIS’s state persistence code for control bars does validate location for floating control bars during loading the state. So, all the control bars will be moved to the nearest desktop areas on their nearest monitors if their floating locations saved into the state data is outside the current desktop.
|
|