I''m currently trying to detect when a dockable control has been closed by the
user and have met the issue that the control''s dispose event and destructor
are not called when the control is closed but when the docking manager itself
is disposed.
Is this a known issue, or is there a way of forcing the docking manager to flush
obsolete controls?
For our purposes, this issue is far more than not being able to tell if a
control has been closed, but implies that the control is still residing in
memory along with any of its data and related objects.
AD
Administrator
Syncfusion Team
March 11, 2005 04:49 PM UTC
Hi Ian,
The Controls are not disposed because closing a docking window is not intended to be permanent. Even after being closed, the docking window can be reopened using SetDockVisibility(). Please take a look at the SDIDemo for DockingManager in our Samples Browser. It demonstrates this functionality.
Regards,
Gregory Austin
Syncfusion Inc.
IY
Ian Yates
March 11, 2005 04:55 PM UTC
I see. So the ''X'' acts as ''Hide'' by default?
Is there a way to change this default behaviour?
Just before your response I managed to use the DockVisibiltyChanged event to fully dispose of the control. Is this the only way to achieve this?
AD
Administrator
Syncfusion Team
March 11, 2005 05:05 PM UTC
Hi Ian,
I don''t believe there is any way built in to DockingManager to disable that functionality as it''s a core feature of the DockingManager.
Handling the DockVisibilityChanged event should be the best way to dispose of the Control, as it''s the event that''s fired whenever the X is clicked (or SetDockVisibility() is called).
Regards,
Gregory Austin
Syncfusion Inc.
IY
Ian Yates
March 11, 2005 05:08 PM UTC
Okay, that''s fine, thanks.
My only remaining issue on this subject is that the ''Hide'' feature also sets the docking visibility, and so, is causing the control to be disposed of by the event.
Ideally I''d like to be able to remove the ''Hide'' feature - something that has been mentioned on these forums before but I haven''t seen a public resolution.
Is this possible?
AD
Administrator
Syncfusion Team
March 14, 2005 03:25 PM UTC
Hi Ian,
I''ve looked into this a bit further and have come up with the following code snippet to remove the Hide option from the context menu:
//Handle the DockContextMenu event
private void dockingManager1_DockContextMenu(object sender, Syncfusion.Windows.Forms.Tools.DockContextMenuEventArgs arg)
{
//Get the PopupMenu
Syncfusion.Windows.Forms.Tools.XPMenus.PopupMenu menu = arg.ContextMenu;
//Will contain a reference to the Hide option on the ContextMenu
Syncfusion.Windows.Forms.Tools.XPMenus.BarItem hideItem = null;
foreach (Syncfusion.Windows.Forms.Tools.XPMenus.BarItem b in menu.ParentBarItem.Items)
{
if (b.Text.Equals("&Hide"))
{
//We found it
hideItem = b;
}
}
//If we found it, remove it
if (hideItem != null)
{
menu.ParentBarItem.Items.Remove(hideItem);
}
}
Hope this helps.
Regards,
Gregory Austin
Syncfusion Inc.
IY
Ian Yates
March 15, 2005 11:09 AM UTC
Thanks for that.
Incase if it''s of any use to somebody else, I''ll post my final solution.
Using your idea of modifying the context menu live (something I hadn''t thought of), I simply renamed the Hide item to Close.
private void dockingManager_DockContextMenu(object sender, DockContextMenuEventArgs arg)
{
// Get the PopupMenu
PopupMenu menu = arg.ContextMenu;
// Loop through to ''Hide'' item
foreach (BarItem item in menu.ParentBarItem.Items)
{
// Rename ''Hide'' item to ''Close''
if (item.Text == "&Hide")
{
item.Text = "&Close";
break;
}
}
}