I`m using the Docking Manager (126.96.36.199) functionality in my application and I have came across several issues:
First, I was surprised not being able to use a foreach statement to iterate thru the Controls in the docking manager, because it doesn`t implement IEnumerable. It exposes an Enumerator so implementing the IEnumerable interface showldn`t be a problem.
Second, because the application is very large, I cannot create docking windows from panels or this type of controls because the functionality is not available in the main MDI Form and it would be a hell if you had many windows in the designer.
I`m using instead Forms, created during the application start. I`m also using state persistency in the isolated storage.
The problem is that i can`t call LoadDockState untill after I create the windows.
You can easily imagine how it looks like. Is quite a show. All the windows are docked using DockControl(...). I cannot create tabs because only the first form will be visible so I create them separately.
And also, when you move the mouse over a hidden window, it should`t show immediately, but wait some amount of time. This also applys to the shown windows. They should`t hide immediately after the mouse left them. The VS.NET is a good example.
This avoids some problems like if you have a hidden window in the top right corner, near a close button, the user has to be very carefull not to put the mouse on that, because the window will immediately expand and cover the button
PSPrakash S Syncfusion Team July 29, 2003 09:44 AM
The DockingManager maintains it's collection of dock-enabled controls through an ArrayList instance rather than a custom Collection type. This would have necessitated that the DockingManager class implement and expose the IEnumerable itself rather than conform to the .NET standard where IEnumerable is usually implemented on a collection type eg., TabControl.TabPages, ToolBar.Buttons etc., We will consider this as a feature request and try to implement this in a future version of Tools.
Please elaborate on the problem that you are facing when using programmatic initialization. Why is it necessary that the dockable controls be created/initialized after your main form has been activated? This can very well be done before the form is displayed, following the InitializeComponent call, and then you will just have to load the persisted dockstate from the DockingManager.NewDockStateEndLoad handler. This should considerably minimize the flicker evident when the state is being loaded.
Thank you for highlighting the problem in the AutoHide mechanism. I have logged a QA report and we will do our best to address the issue in a future version of Essential Tools.
SASerban Alexandru FlorianJuly 31, 2003 07:33 AM
Is necessary that the dockable controls be created/initialized after the main form has been activated because this app is using user rights to control the amount of user access.
When the app starts it presets the user with a login window. After validating the user rigts, the windows were the user has access are created.
The diffrent types of windows represent diffrent
types of user documents (faxes,documents,etc). To inform the user where he gets new ones, I do a flashing icon thing, seting a timer to put an icon, then a trasparent one, and so on until it clicks inside the form because I cannot know when he clicks on the caption window or the title area.
Also I can change the caption, but not when the window is floating beacuse it takes the last caption of when it was docked.
When the user logs off,all of the windows are distroyed.
Also I have some problems here because sometimes, when a window is docked and shown, but not pined (it has focus so it stays open)
and i press the logout button, the windows destroing code kicks in, but it crashes with a IndexOutOfBounds exception and the window surface is drawn with a red x.
Could you please give me a small sample with what should I do to safely destroy the windows?
Now I use something like:
PSPrakash S Syncfusion Team August 7, 2003 09:38 AM
The caption failing to update for floating controls till they are redocked is a known issue that we very recently fixed. Regarding disposal of dockable windows, all that is required is to invoke the DockingManager.SetEnableDocking() call on the Control with a FALSE parameter. However, I did notice that autohidden windows were causing a crash when attempting to dispose them off in the manner that you have attempted. This problem has now been fixed. Future updates of Essential Tools will ship with the revised code that includes fixes for both these issues. My apologies for the inconvenience.
ADAdministrator Syncfusion Team August 20, 2003 03:49 PM
" The caption failing to update for floating controls till they are redocked is a known issue that we very recently fixed. "
What is the fix. I start my user controls as floating and the proper SetDockLabel title won't show until I dock them.
CCCharles CarlinAugust 27, 2003 07:21 AM
I am seeing both of these issues when will the patch be available?
ADAdministrator Syncfusion Team August 28, 2003 02:11 PM
Please go ahead and log a request for this fix through Direct Trac and we will send you a private patch.
GPGuru PatwalJanuary 29, 2004 11:45 AM
This is regarding the following issue :
>>> And also, when you move the mouse over a hidden window, it should`t show immediately, but wait some amount of time.
The DockingManager now includes a new AutoHideInterval property that permits the show/hide interval for autohidden controls to be set by the application. The default interval has also been increased to 400 milliseconds to allow a bit of leniency in mouse movement over the tabs. This property is expected to be included in the next build of Essential Suite. Thanks for considering Syncfusion products.