How goofy can FindControl get anyway?

  • Thread starter Thread starter Hillbilly
  • Start date Start date
H

Hillbilly

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.FindControl("CenterPanelContent
$ItemBuilderWizard
$StepNavigationTemplateContainerID
$StepNavFinalStepButton") as Panel;

// "normal form" object not found...
Panel finalStepButton =
Page.Master.FindControl("CenterPanelContent")
..FindControl("ItemBuilderWizard")
..FindControl("StepNavigationTemplateContainerID")
..FindControl("StepNavFinalStepButton") 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 :-)
 
FindControl does not do recursive searches. it only searches the naming
container of the control its called from. to get around this limitation
FindControl also supports a fully qualified path. so if you want to find
ctl1 which is a child of parent1, and parent1 is a child of topparent,
and topparent is a control in the Page control collection, then you can
lookup ctl1 by its fully qualified path:

Page.FindControl("topparent$parent1$ctl1")

if you are searching from topparent then its

FindControl("parent1$ctl1")


note: you can use ":" or "$" as a delimiter

-- bruce (sqlwork.com)
 
Somewhere long ago I recall reading not to do that and got into the habit of
concatenating FindControl("...").FindControl("...") on each part of the
tree.

The $ delineator had something to do with being used to find controls using
client-side code. Do you remember or know of the context I'm thinking about?
Do you think I'm confusing ClientID with some other context?

Again, the wierdest part is being able to use delineators but not
concatenating when concatenating functions as intended in other places in
the same code. This is all in Master Pages which may incur some of its own
wierdness.
 
Hillbilly said:
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.FindControl("CenterPanelContent
$ItemBuilderWizard
$StepNavigationTemplateContainerID
$StepNavFinalStepButton") as Panel;

// "normal form" object not found...
Panel finalStepButton =
Page.Master.FindControl("CenterPanelContent")
.FindControl("ItemBuilderWizard")
.FindControl("StepNavigationTemplateContainerID")
.FindControl("StepNavFinalStepButton") 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 :-)
Click to expand...

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.Control initialControl,
string id) where T : System.Web.UI.Control
{
if (initialControl.ID == id && initialControl is T)
{
return initialControl as T;
}

System.Web.UI.ControlCollection controls = initialControl.Controls;
foreach (System.Web.UI.Control ctl in initialControl.Controls)
{
System.Web.UI.Control 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.
 
Back
Top