AutoHide Doesn't Seem to Work for Right-Docked ToolWindows

[Jeremy Murtishaw]

Hello,

I have a RadForm containing a RadDock and one left-docked toolwindow, one fill toolwindow and three right-docked toolwindows. I am experiencing three problems.

First, because I don't want the Right-docked tabs to be visible on form load, I call the .Hide() method to hide the three tool-windows. Later, when I want their tabs to be visible, I call the .AutoHide() Method for the right tool-windows, and for some reason they display their tabs on the left side of the screen. When you hover over the tabs, they slide out from the left side, but if you click the auto-hide button, they dock on the right side of the form. I have found a BAD workaround, which involves calling the .Show() method just before the .AutoHide() method, but this causes a lot of drawing artifacts and ugliness on the screen. 

Second, in this same configuration, when I originally launch the form, by clicking a button on the MdiParent, the first thing I see is one of my right-docked toolwindows slide-opening animation, hovering in space, then disappearing, prior to the rest of the form displaying. Weird.

Third, If I have all three right-docked windows auto-hid, and hover over their tabs in sequence, it appears that the tabs do not hide when i move from one to the next, but in fact, all three stay open, with the last one on top of the first two. Thus, when I click the icon to turn off auto-hide and dock the window permanently, it actually opens all three in this manner, not just the last one I hovered over, as you'd expect.

Any help would be appreciated.

Jeremy

[Georgi]

Hi Jeremy,

Thank you for contacting us.

Regarding the problems you are experiencing:

1. Determining the auto-hide position is based on the location of the tool window towards the MainDocumentContainer. If, at the time of becoming auto-hidden, there is no document container, then the panel will select the default edge (that is Left) to be auto-hidden against. You can explicitly specify the desired auto-hide position like this:

private void SetAutoHidePosition()
{
    ToolTabStrip strip = this.toolWindow1.DockTabStrip as ToolTabStrip;
    if (strip != null)
    {
        strip.AutoHidePosition = AutoHidePosition.Right;
    }
}

Please, note that the ToolTabStrip reference will be available when the tool window is added on the RadDock scene.

2. This is most probably due to the ActiveWindow property of RadDock pointing to an auto-hidden window. When RadDock is loading, it will attempt to activate its current ActiveWindow, which process will force an auto-hidden window to be displayed. You can easily change the ActiveWindow property to point to some docked window.

3. This is the behavior by design. It is much like in Visual Studio itself - you have the so called "Auto-hidden group", which may include one or more Tool Windows. Their state is altered in batch - e.g. entire group will become Docked or AutoHidden. Such a group for example is a ToolTabStrip with several ToolWindows docked as Tabs in it. Showing/Hiding the auto-hide host is performed using animations, that is causing the visual impression that the previous window is not hidden. You may specify the desired animation like this:

this.radDock1.AutoHideAnimation = AutoHideAnimateMode.None;

Please, let me know whether this is of help.


Kind regards,
Georgi
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.

[Jeremy Murtishaw]

Hi Georgi,

Here's my responses to your recommendations:

1. Unfortunately, I could not get this solution to help me with my issue... Although I acknowledge that your code will position the ToolTabStrip autohide component on the Right [if it exists], it doesn't work when the toolWindows are hidden. At the time they're hidden, the ToolTabStrip reference is null, and so you are unable to set that property, as you mentioned. When they are unhidden, via the autohide() method, the property is set to auto, and the window docks to the left, also as you mentioned. It seems to be a bug that they do not assume their proper position as delineated at design time, but they do if you call show() prior to calling autohide(). So, in summary, when you call show() on a toolwindow in a hidden state, it goes to the correct position, but when you call .autohide() on a hidden toolwindow, it does not. In an attempt to workaround this issue, I tested about 25 events to see if I could insert your code in between the .autohide() call and the docking of the window on the left. Although some of my events were fired, and I set that property as you suggested, it failed to position the toolWindow on the right. I've also tried explicitly setting the ToolTabString.AutoHidePosition property without testing for the relationship in advance. I can't get anything to work, so I'm still stuck with my other bad workaround. If you test this scenario, I think you'll find that it is very difficult, if not impossible to go from hidden to autohidden on the predefined side of the screen. Any solution you can come up with would be greatly appreciated.

2. Using your recommendation, I've gotten around this issue [i think] by handling the ActiveWindowChanging event of the RadDock during form initialization and cancelling all of the events. However, it was sporadic before and maybe I'm just getting lucky. I'll repost after you get back to me about the other two.

3. On this one, I've now seen the behaviour act both ways, so I don't see how it can be as designed, haha. I mean that while originally I saw it behave as described below, it now behaves the way I want, and I haven't changed anything! In addition, the open animation and clicking on the tabs has proven to be extremely buggy. Sometimes hovering over the tab will not cause it to slide out, but clicking it will. Sometimes, it takes several clicks to open, and sometimes it does not open at all. Sometimes everything seems to work just fine. Another weird case of randomness in computers, which are not really supposed to act randomly ;-) The last thing I will note is that I've noticed that the AutoHideAnimation is defaulted to only when it slides out. I figured it would be nice to slide both ways and tested that setting. Now I see why the default is the way that it is. The painting on the slide in animation is bad, causing the area that the tab once took up to not be painted. Instead, you just see the repeated left (or right) edge of your toolwindow until the animation finishes, at which point it all clears. 

Thanks!

Jeremy

[Georgi]

Hi Jeremy,

Thank you for getting back to me and for your detailed response.

Regarding the issues:

1. Generally you are correct, the behavior of RadDock, when determining the auto-hide edge, may be more intuitive - e.g. it may check what was the ToolWindow's position BEFORE it became hidden. Actually we will do so for our next major release - Q3 2009. Since you are auto-hiding the window by code, you can do a simple workaround here:

Instead of calling ToolWindow.AutoHide, use the RadDock's method:

this.radDock1.AutoHideWindows(new DockWindow[] {this.toolWindow1}, AutoHidePosition.Right);

2. You may simply specify for ActiveWindow some DockWindow that is already displayed - it may be either DocumentWindow (TabbedDocument) or ToolWindow.

3. There is an already known issue with preserving AutoHideSize setting for a tool window and this issue will be addressed for Q3 2009. Animating show/hide for auto-hidden windows uses the native Win32 API AnimateWindow, which will block the UI thread until animation is complete. This can perform badly for heavy applications and that is why RadDock exposes the animation setting. Unfortunately I am not able to reproduce the auto-hidden windows display problem (its randomness to be more precise). I will perform deeper tests in order to diagnose any potential issue with that. In the mean time, if you have a sample application that demonstrates the problem, it will be most helpful.

I would like to thank you for your feedback and for reporting these issues. Your Telerik points are updated accordingly.

Please, do not hesitate to write back if you have further questions.


Regards,
Georgi
the Telerik team

Instantly find answers to your questions on the new Telerik Support Portal.
Watch a video on how to optimize your support resource searches and check out more tips on the blogs.