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;
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;
ADAdministrator Syncfusion Team March 28, 2005 03:22 PM
Please try calling DockingManager.HideAutoHiddenControl() before SetDockVisibility(). It should solve your problem.
KLKen LawMarch 28, 2005 05:35 PM
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 184.108.40.206beta.
ADAdministrator Syncfusion Team March 28, 2005 06:01 PM
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.
KLKen LawMarch 28, 2005 06:23 PM
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?
ADAdministrator Syncfusion Team March 29, 2005 12:46 PM
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.
GMGuillem MazaricoMarch 30, 2005 03:48 AM
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.
ADAdministrator Syncfusion Team March 30, 2005 02:00 PM
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.
GMGuillem MazaricoMarch 31, 2005 03:07 AM
> That behavior is intended. [...]
>Please let me know if you have any further questions about this.
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.
ADAdministrator Syncfusion Team March 31, 2005 01:30 PM
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)
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.