The Q2 2009 RadDock control does not SetStyle(ControlStyles.ContainerControl) and so is not seen in .net as a ContainerControl. This causes problems when calling Form.ValidateChildren or Control.Validate to force validation of controls held in a RadDock window.
My workaround is to explicitly handle the radDock_Validating event in my code like this;
private void radDock_Validating(object sender, CancelEventArgs e)
{
if(! ((ContainerControl)this.radDock.ActiveWindow).Validate())
{
e.Cancel = true;
}
}
The .net framework behaves oddly when cascading the Validate event through a control stack, and instead of simply iterating a controls .Controls collection, it explicitly checks to see if a the Control.GetStyle(ControlStyles.ContainerControl) is true before deciding to iteratve the .Controls collection. Because RadDock does not set this property it is in effect telling the .net Framework "I don't have any children, so don't bother looking any further". By manually cascading the Validating event as shown above, we jump this gap.
I don't know if this particular pattern is followed in any other cascading functionality in the .net framework.
My workaround is to explicitly handle the radDock_Validating event in my code like this;
private void radDock_Validating(object sender, CancelEventArgs e)
{
if(! ((ContainerControl)this.radDock.ActiveWindow).Validate())
{
e.Cancel = true;
}
}
The .net framework behaves oddly when cascading the Validate event through a control stack, and instead of simply iterating a controls .Controls collection, it explicitly checks to see if a the Control.GetStyle(ControlStyles.ContainerControl) is true before deciding to iteratve the .Controls collection. Because RadDock does not set this property it is in effect telling the .net Framework "I don't have any children, so don't bother looking any further". By manually cascading the Validating event as shown above, we jump this gap.
I don't know if this particular pattern is followed in any other cascading functionality in the .net framework.