asp.net FindControl方法誤區和解析

1．認為FindControl方法尋找的範圍是給定Control的後代控制項。
複製代碼 代碼如下:<form id="form1" runat="server">
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
<asp:Panel ID="Panel1" runat="server">
<asp:TextBox ID="TextBox1" runat="server"></asp:TextBox>
<asp:Button ID="Button1" runat="server" Text="Button" />
</asp:Panel>
</form>

如上面代碼，後台用Panel1.FindControl("Button1")尋找，認為這樣範圍小些可以提高效率，其實即使用TextBox1.FindControl("Button1")也一樣能找到。前有所述，FindControl方法是根據ID在Control所在的命名容器中尋找相應控制項。當執行TextBox1.FindControl("Button1")時，ASP.NET先擷取TextBox1.NamingContainer，其值為頁面本身（最後產生的xxxx_aspx類執行個體），再向下遞迴尋找相應ID的控制項，所以一樣能找到Button1。

同樣的，如果用TextBox1.FindControl("Label1")也是能找到Label1的。

2．不理解為什麼this.FindControl方法找不到GridView裡的控制項。

其實很好理解，FindControl方法尋找時只在本命名容器下尋找，不會進入其他命名容器中尋找，而命名容器（NamingContainer）不只是頁面本身，還包括GridViewRow、DataListItem、RepeaterItem、UserControl、MasterPage等等諸多控制項，這些都繼承了INamingContainer介面，它們的一個顯著特徵是其子控制項的UniqueID和ClientID一般都不同於ID（除了頂層的頁面對象）。

3．認為FindControl運行效率差。

實際上ASP.NET運行時分析aspx、ascx、master等檔案標籤結構，產生類似Dom的控制項樹，一般對樹的查詢操作效率還是比較高的，尤其當問題規模不太大時。一般來說，實際頁面裡的控制項數量不可能成千上萬，而且尋找時又不能越過本命名容器，這些因素限制了問題規模。所以說FindControl的效率並不差。