My application has a set of controls that dock to the left side of the parent form. I instantiate these controls once, but hide/show them depending on what "mode" my program is in.
All the controls are set to auto-hide. Everything seems to work fine as long as the controls are "auto-hidden" when I change modes. However, if they are visible when I change modes, the currently visible control is not hidden, and the control that should show up in the new mode does not - the control from the prior mode remains. Here is the code that clears the current controls when I leave a mode:
foreach (object o in this.alCurLayoutControls)
{
Control control = o as Control;
this.oDockingManager.SetDockVisibility(control, false);
}
And here is the code to show other controls in the new mode:
foreach (DictionaryEntry de in task.TreeControls)
{
Control control = ((TC)de.Value).TreeControl;
this.alCurLayoutControls.Add(control);
this.oDockingManager.SetDockVisibility(control, true);
this.oDockingManager.SetAutoHideMode(control, true);
}
Any ideas?
AD
Administrator
Syncfusion Team
March 28, 2005 08:22 PM UTC
Hi Ken,
Please try calling DockingManager.HideAutoHiddenControl() before SetDockVisibility(). It should solve your problem.
Regards,
Gregory Austin
Syncfusion Inc.
KL
Ken Law
March 28, 2005 10:35 PM UTC
Thanks Gregory, that seems to have done the trick.
The HideAutoHiddenControl() is not shown as a member of DockingManager in my integrated help. Might I have an old version of help? I''m running 3.1.0.5beta.
Thanks,
-Ken
AD
Administrator
Syncfusion Team
March 28, 2005 11:01 PM UTC
Hi Ken, It's possible that HideAutoHiddenControl() has only recently been added to the documentation and/or that you have old documentation. It is currently included in our
online documentation. I've also dug around a little bit and confirmed that HideAutoHiddenControl() is not a new addition. It's been a part of DockingManager since before v2.0, so you shouldn't have any problem using it in your application. Regards, Gregory Austin Syncfusion Inc.
KL
Ken Law
March 28, 2005 11:23 PM UTC
Hi Gregory,
The HideAutoHiddenControl() call did not completely fix the problem. If the AutoHide control is not pinned and is in the process of hiding when I make the switch, the problem occurs.
The Visual Studio tool tip help attached to HideAutoHiddenControl says "Hides the locked autohidden control". My autohidden control is not locked, could this be the problem?
Thanks,
-Ken
AD
Administrator
Syncfusion Team
March 29, 2005 05:46 PM UTC
Hi Ken,
I believe that "locked" refers to the window being open and having focus, as opposed to being pinned. However, I have managed to reproduce the problem you describe, if I attempt to hide the control in the short window during which it is closing, the original error will occur.
I have entered this as
Defect #146. I have included a second workaround at the above link. Please let me know if you have any further questions.
Regards,
Gregory Austin
Syncfusion Inc.
GM
Guillem Mazarico
March 30, 2005 08:48 AM UTC
Hi Gregory,
I have a question on another matter, but still about the docking manager. And since this ''bug'' is visible when you reproduce the bug submitted above...
When a control is tabbed (appears as a tab in a bar on a side of the screen), and its dock visibility is changed, it disappears, which is totally fine. But when its dock visibility is restored, the control does not reappear tabbed, but docked. Is this a bug ? In case this is the standard behavior, is there a way to programatically tab a docked control ? That would be useful for an eventual workaround.
Thanks
AD
Administrator
Syncfusion Team
March 30, 2005 07:00 PM UTC
Hi Guillem,
That behavior is intended. If you try the same thing in VS .NET, you''ll notice that the exact same thing happens. Closing and reopening an auto-hidden window in VS .NET will result in a the window being docked instead of auto-hidden. Please let me know if you have any further questions about this.
Regards,
Gregory Austin
Syncfusion Inc.
GM
Guillem Mazarico
March 31, 2005 08:07 AM UTC
>Hi Guillem,
>
> That behavior is intended. [...]
>Please let me know if you have any further questions about this.
Hi Gregory,
thank you for your answer. Indeed I have a question (the last one from my previous post): "In case this is the standard behavior, is there a way to programatically tab a docked control ? That would be useful for an eventual workaround."
It sounds like you are limiting your docking manager willingly to stick to the one included in Visual Studio. My own 2 cents is that you are limiting needlessly your control(s). While the standard behavior could be Visual Studio''s, there are many features that could augment it and make it a more complete control: colored tabs is a good example.
While it is true that the user can and should build the features he wants on the base you laid with the basic Syncfusion control, sometimes the latter is not really very easy to deal with (or maybe it is, but there is a strong lack of user documentation).
Thansk for reading.
Regards
AD
Administrator
Syncfusion Team
March 31, 2005 06:30 PM UTC
Hi Guillem,
I apologize for overlooking your question. The event DockVisibilityChanged will fire whenever the visiblity of a docked control changes, allowing you to set whatever properties you need. The following code snippet demonstrates automatically setting controls that are made visible to AutoHideMode:
private void dockingManager1_DockVisiblityChanged(object sender, Syncfusion.Windows.Forms.Tools.DockVisibilityChangedEventArgs arg)
{
if (this.dockingManager1.GetDockVisiblity(arg.Control))
{
this.dockingManager1.SetAutoHideMode(arg.Control, true);
}
}
Regarding the documentation, we have put a lot of work into updating it for our latest release.
Regarding our imitation of VS .NET, our goal is to have our products default to working how people would expect them to work. Someone who has spent a great deal of time working with the docking windows in VS .NET would likely expect a closed and then reopened window to not be auto-hidden. We then add features (such as DockVisibilityChanged) that allow customization of this default behavior, so that people who want a different behavior can change it.
Regards,
Gregory Austin
Syncfusion Inc.