"Hillbilly" <so******@somew here.comwrote in message
news:Oy******** ******@TK2MSFTN GP05.phx.gbl...
Maybe this is or isn't some kind of bug but it sure is goofy and remains a
mystery that really has me puzzled for two reasons...
// goofy syntax functions as expected...
Panel finalStepButton =
Page.Master.Fin dControl("Cente rPanelContent
$ItemBuilderWiz ard
$StepNavigation TemplateContain erID
$StepNavFinalSt epButton") as Panel;
// "normal form" object not found...
Panel finalStepButton =
Page.Master.Fin dControl("Cente rPanelContent")
.FindControl("I temBuilderWizar d")
.FindControl("S tepNavigationTe mplateContainer ID")
.FindControl("S tepNavFinalStep Button") as Panel;
1.) Why does the $ delineator even allow finding the control server-side
when it is used to delineate the ClientID?
2.) Why does the $ delineator over-ride the normal form of FindControl at
all?
Ugly Betty or not, I'm just glad some "thing" works once in awhile :-)
I use the following as a replacement, it does a recursive search and returns
a typed control:
public static T FindControl<T>( System.Web.UI.C ontrol initialControl,
string id) where T : System.Web.UI.C ontrol
{
if (initialControl .ID == id && initialControl is T)
{
return initialControl as T;
}
System.Web.UI.C ontrolCollectio n controls = initialControl. Controls;
foreach (System.Web.UI. Control ctl in initialControl. Controls)
{
System.Web.UI.C ontrol nextCtl = FindControl<T>( ctl, id);
if (nextCtl != null)
{
return nextCtl as T;
}
}
return default(T);
}
You normally pass in the Page itself as the first parameter but you can
improve performance by starting lower down the tree if possible.
The generic parameter T specifies the type of control you are searching for.
If the control is not found then null is returned.
--
Joe Fawcett (MVP - XML)
http://joe.fawcett.name 
