asp.net的控件

asp net的控件分为内置和外置两种。asp net的内置控件分为两种：HTML 控件 (HTML control)和用户控件 (User control)。外置控件，在使用前，需要将其添加到Visual Studio NET环境中。然后就可以通过启动一个新项目来使用新的控件。 虽然有的时候，控件在开发机器上运行正常，但当程序被部署到终端用户机器上时，会出现问题。因为很多终端机器不允许安装外置控件，对于上述问题有简单实用的解决办法-“在服务器上部署 “fp_client” 文件夹”。

fp_client 文件夹包含所有ASPNET外置控件需要的脚本文件。 拿Spread控件为例，Web 页面上的 Spread 控件实例从服务器上的 fp_client 文件夹中读取前台格式化、样式和脚本功能。　　fp_client 文件夹的默认安装路径是：C:\Program Files\GrapeCity\SpreadASP5dotNet20\v502015\fp_client\fpspread\5_0_2015_2008\HTC

我们需要在 webconfig 文件中添加以下代码 fp_client 文件夹进行正确的加载： <appSettings><addkey=fp_clientvalue=fp_client/></appSettings>下面是两个有助于我们更加深入的去解决该问题问题的相关点：　　1上面的标签仅在你想要从程序根目录下载“fp_client”文件夹是需要 ，在这种情况下，你需要复制 fp_client 文件夹并且把它粘帖到程序的根目录下，或者创建一个映射到 fp_client 文件夹的虚拟路径。　　2在服务器上有很多网址运行 Spread for ASPNET，我们仅需要把 fp_client 文件夹 复制到服务器的根目录上即可（而不是程序的根目录）。在这种情形下， 上述 webconfig 标签是不需要添加的，程序仍然可以完美运行。 1、ClientIDMode

渲染ASP NET控件时会自动生成一个ID,当在客户端脚本中引用它们时,却会制造不少麻烦,虽然它是命名容器和ID的简单串联,但仍然无法预测生成的ID范围

ASP NET 40使用ClientIDMode属性解决了这个问题,它允许控制生成这些ID的方法,ClientIDMode有四个可选择的值:AutoID,Static,Predictable和Inherit下面是这四个值的含义解释:

AutoID – 和40以前的版本保持一致,自动生成ID

Static – 指定ID的值,在渲染控件时不会发生变化

Predictable – 指定后缀,然后和容器控件的ID属性进行合并

Inherit – 继承父控件的设置

注意,Page的默认ClientIDMode属性的值是AutoID,可以通过@ Page指令设置页面级的值,还可以通过修改Web配置文件设置应用程序级的值

[pre]

<systemweb>

<pages clientIDMode=Predictable></pages> </systemweb>

[/pre]

2、Meta关键字和Meta描述

在ASP NET 40中Page类增加了两个新的属性:Meta Keywords和Meta Description,可以在运行时设置这两个属性,通过数据库或其它源驱动,并允许动态设置标签,描述特定的页面,下面的Page标签显示了这两个属性 [pre]<%@PageLanguage=C#AutoEventWireup=trueKeywords=keyword1,keyword2Description=mydescription%>C#AutoEventWireup=trueKeywords=keyword1,keyword2Description=mydescription%>C#AutoEventWireup=trueKeywords=keyword1,keyword2Description=mydescription%>[/pre]3、数据绑定控件中的行持久性选择

ASP NET数据绑定控件,如Grid View,都支持行选择,但它们应该选择每个页面上相同编号的行,但ASP NET 40以前的版本中,行持久性选择是不能实现的,因为以前的版本选择后续页面上的行时是基于行索引的,ASP NET 40提供了一个直观的方法解决了这一问题

数据绑定控件现在提供了一个EnablePersistedSection属性,它可以帮助实现行持久性选择。

4、AutoEventWireup

AutoEventWireup是很少使用但知名度很高的一个ASP NET属性,简单地说,它设置为True时,在未明确委派的情况下,允许自动调用页面事件。

它的默认值是True,AutoEventWireup属性的缺点在MSDN上有详细描述:它限制了命名事件处理程序的灵活性,另一个缺点是对性能的不利影响,对于高流量的网站,性能影响是巨大的

5、Page的Header属性

Page类现在提供了Header属性,可以在运行时绑定它,下面的代码示例显示了如何明确设置Title属性

thisHeaderTitle = My page title;

当根据某个规则动态关联一个样式表时,这个属性非常方便,在这种情况下,打印页面是理想的候选 [pre]HtmlLinkprintLink=newHtmlLink();printLinkAttributesAdd(type,text/css);printLinkAttributesAdd(rel,stylesheet);printLinkAttributesAdd(href,css/printcss);thisHeaderControlsAdd(printLink);[/pre]6、AssociatedControlID属性

可以在一个Web表单中将一个控件关联到另一个服务器控件,这时需要使用服务器控件的AssociatedControlID属性,当根据某些行为为关联的控件设置热键时,这个属性就可以派上用场了

AssociatedControlID属性的默认值是一个空字符串,它表示控件未与任何服务器控件关联,下面的代码显示了一个Textbox控件是如何与Label服务器控件关联的

7、ControlState属性

ASP NET最重要的状态管理技术是ViewState,它允许你在往返Web服务器的路上保留值,但由于可在父级关闭,它并不是保存信息可靠的方法

ASP NET 20为服务器控件引入了私有的ViewState,叫做ControlState,它可用来存储控件的关键信息,ASP NET可以处理它的序列化和反序列化

注意,使用时必须谨慎,因为它会影响页面的性能

8、ControlPreserveProperty

针对传统的视图状态用法,Rick Strahl为我们提供了另一个选择:PreservedProperties,它可以保存控件ID和属性名称,详细信息请参考Implementing an ASP NET PreserveProperty Control(实现ASP NET PreserveProperty控件)

9、PreviousPageType指令

PreviousPageType指令是ASP NET 20跨页面回送机制的一部分,允许指定来源页面的虚拟路径,以便强类型访问来源页面正常情况下,发送的数据可通过PreviousPage属性和FindControl方法访问,但使用强类型的PreviousPageType指令允许你访问公共属性,而不需要调用FindControl方法

WEB服务器控件是HTML控件的一种扩展,区别是:

1)前者可以触发服务器控件特有的事件，后者只能通过回递的方式触发服务器上的页面级事件。

2)输入到前者中的数据在请求之间可以维护（即具有状态管理功能）,而后者无法自动维护数据，只能使用页面级的脚本来保存和恢复。

3)前者可以自动检测浏览器并调整到恰当的显示，而后者没有自动适应功能，必须在代码中手动检测浏览器。

4)每个服务器控件都具有一组属性，可以在服务器端的代码中更改控件的外观和行为，而后者只有HTML属性。

如果某些控件不需要服务器端的事件或状态管理功能时，可以选择HTML控件，这样可以提高应用程序的性能 百度搜索里面不是很多这样的问题吗 。 就如我最后所说的，在不是一定需要使用服务器控件的时候最好用html控件，因为每次页面运行，里面的服务器控件会向服务器里请求数据及其他，这里会占用一定的资源时间。 如有问题请追问。

ASPNET为开发人员提供了一整套完整的服务器控件来验证用户输入的信息是否有效。这些控件如下：

1、RequiredFieldValidator：验证一个必填字段，如果这个字段没填，那么，将不能提交信息。

2、CompareValidator：比较验证。比较两个字段值是否相等，如密码和确认密码两个字段是否相等；比较一个字段与一个具体的值。

3、RangeValidator：范围验证。验证一个字段是否在某个范围中，如成绩字段要是0~100范围中。

4、RegularExpressionValidator：正则表达式验证。它根据正则表达式来验证用户输入字段的格式是否合法，如电子邮件、身份证、电话号码等。

5、CustomValidator：在运行定制的客户端JavaScript或VBScript函数时，可以使用这个控件。

(1)初始化:在此阶段中，主要完成两项工作：一、初始化在传入Web请求生命周期内所需的设置;二、跟踪视图状态。首先，页面框架通过默认方式引发Init事件，并调用OnInit()方法，控件开发人员可以重写该方法为控件提供初始化逻辑。此后，页面框架将调用TrackViewState方法来跟踪视图状态。需要注意的是：多数情况下，Control基类提供的TrackViewState方法实现已经足够了。只有在控件定义了复杂属性时，开发人员才可能需要重写TrackViewState方法。

(2)加载视图状态:此阶段的主要任务是检查ASPNET服务器控件是否存在以及是否需要将其状态恢复到它在处理之前的请求结束的状态。因此该过程发生在页面回传过程中，而不是初始化请求过程。在此阶段，页面框架将自动恢复ViewState字典。如果服务器控件不维持其状态，或者它有能力通过默认方式保存其所有状态而使用ViewState字典，那么开发人员则不必实现任何逻辑。针对那些无法在 ViewState字典中存储的数据类型或者需要自定义状态管理的情况，开发人员可以通过重写LoadViewState方法来自定义状态的恢复和管理。

(3)处理回发数据:若要使控件能够检查客户端发回的窗体数据，那么必须实现SystemWebUIIPostBackDataHandler接口的 LoadPostData()方法。因此只有处理回发数据的控件参与此阶段。

(4)加载:至此阶段开始，控件树中的ASPNET服务器控件已创建并初始化、状态已还原并且窗体控件反映了客户端的数据。此时，开发人员可以通过重写OnLoad()方法来实现每个请求共同的逻辑。

(5)发送回发更改通知:在此阶段，ASPNET服务器控件通过引发事件作为一种信号，表明由于回发而发生的控件状态变化(因此该阶段仅用于回发过程)。为了建立这种信号，开发人员必须再次使用SystemWebUIIPostBackDataHandler接口，并实现另一方法- RaisePostBackChangedEvent()。其判断过程为：如果控件状态因回发而更改，则LoadPostData()返回true;否则返回false。页面框架跟踪所有返回true的控件并在这些控件上调用RaisePostDataChangedEvent()。

(6)处理回发事件:该阶段处理引起回发的客户端事件。为了便于将客户端事件映射到服务器端事件上进行处理，开发人员在此阶段可以通过实现 SystemWebUIIPostBackEventHandler接口的RaisePostBackEvent()方法来实现该逻辑。由此途径，服务器控件将成功捕获回发的客户端事件进行服务器端的相应处理。

(7)预呈现:该阶段完成在生成控件之前所需要的任何工作。通常情况下是通过重写OnPreRender()方法完成该工作。需要注意的是：在该阶段，可以保存在预呈现阶段对控件状态所做的更改，而在呈现阶段进行的更改则会丢失。

(8)保存状态:如果ASPNET服务器控件不维持状态，或者它有能力通过默认方式保存其所有状态而使用ViewState字典，那么开发人员不必在该阶段实现任何逻辑。因为这个保存状态的过程是自动的。如果ASPNET服务器控件需要自定义状态保存，或者控件无法在ViewState字典中存储特殊的数据类型，则需要通过重写SaveViewState()方法来实现状态保存。

(9)呈现:表示向HTTP输出流中写入标记文本的过程。开发人员通过重写Render()方法使其在输出流上自定义标记文本。

(10)处置:在此阶段中，通过重写Dispose ()方法完成释放对昂贵资源的引用，如数据库链接等。

(11)卸载:完成的工作与"处置"阶段相同，但是，开发人员通常在Dispose()方法中执行清除，而不处理Unload事件。