ArcGIS.Server.9.2.DotNet的ADF的Toolbar工作过程分析
目的：
1.ArcGIS.Server.9.2.DotNet的ADF的Toolbar工作过程原理。
开始：
Toolbar工作过程：
一.初始化过程（在页面生成的时候Toolbar控件会生成和它相关的html代码和javascript代码）：
1.根据每一个子Tool生成一个<TD>...</TD>，并且这个TD元素添加onMouseDown、onMouseOver、onMouseOut三个鼠标事件，这样使得TD可以点击执行不同的功能。
2.在javascript中初始化Toolbar1_Items数组，用ToolbarItemObject初始化每一个子Tool添加到Toolbar1_Items数组中。
3.初始化Toolbars数组，用ToolbarObject初始化Toolbar1添加到Toolbars数组中。
4.初始化ToolbarGroups数组，ToolbarGroupObject初始化添加到ToolbarGroups数组。
5.对Toolbar1对象赋一些初始化属性。
二.执行过程（从点击到提交服务端的整个过程）：
1.当Toolbar的Tool被点击时会执行onMouseDown事件的ToolbarMouseDown方法，这个方法定义在ADF的display_toolbar.js中，对于onMouseOver、onMouseOut这2个事件没有实质性的功能是显示效果的切换而已。
2.ToolbarMouseDown方法执行会根据点击的Tool类型进行不同的处理，对于Command和DropDownBox类型的Tool就调用postBack方法直接向服务端进行提交而且对于Tool类型的Tool则根据ClientAction类型调用不同的方法设置地图的操作状态。
3.Tool类型的Tool的ClientAction类型内置了很多如Point、Line、Polyline等根据这个类型会分别调用MapPoint、MapLine、MapPolyline等方法设置地图的操作状态，这些MapPoint方法等是定义在ADF的display_map.js文件中，这些方法执行会调用map对象的setTool的方法设置地图操作状态。
4.设置完地图操作状态就接下来，是进行地图操作了该画点的就画点该画线的就画线了。这些操作是对地图进行操作了那么这些操作代码肯定是在map对象上了，上面的setTool的方法会为map对象的divObject设置onmousedown事件。
5.接着往下执行onmousedown事件调用方法MapMouseDown，这个方法会根据操作类型是结束操作提交结果还是继续设置onmouseup和onmousemove，这个是根据操作类型决定，比如一次性操作的画点到这里就结束操作调用postBack方法向服务端提交结果，而连续操作的画线到这里还需要往下操作就设置onmouseup和onmousemove。
6.最后就执行onmouseup事件的方法MapMouseUp向服务端提交操作结果完成所有动作。
7.上面无论哪种类型的操作殊途同归最终都是需要调用postBack方法向服务端提交结果完成操作，这个postBack方法定义在ADF的display_dotnetadf.js文件中。
8.继续看postBack方法，这个方法执行会调用clientPostBack方法，这个方法是通过eval(callBackFunctionString)方法实现向服务端的提交，跟踪调试可以看到eval(callBackFunctionString)其实就是执行WebForm_DoCallback('Map1',argument,processCallbackResult,context,postBackError,false)这样的方法，到这里一切都明朗了，ADF的类库最终也是通过这种方式像服务端提交数据了，这个和我们自己用Page.ClientScript.GetCallbackEventReference方法产生脚本字符串放在客户端执行一样。
9.现在把ADF产生的WebForm_DoCallback和我们自己用Page.ClientScript.GetCallbackEventReference方法的做一个比较：
ADF: WebForm_DoCallback('Map1',argument,processCallbackResult,context,postBackError,false)
自己：WebForm_DoCallback('__Page',argument,processCallbackResult,context,processCallbackError,true)
10.看上面这2个方法最大的区别就是请求的目标对象不同一个是“Map1”控件一个是“__Page”页面了，由此可见“Map1”控件肯定实现了ICallbackEventHandler的接口
，它能处理ADF脚本方法提交的请求。
11.更进一步，我们在使用Toolbar控件时可以为Tool设置处理的类功能，就是给Tool设置ServerActionAssembly和ServerActionClass属性，这样就说明Map控件还具有一个功能就是能根据发起请求的Tool不同载入我们定义的ServerActionClass类来处理Tool的请求，这样就达到了让用户自己定义Tool的服务端的处理功能。
总结：通过对Toolbar工程流程的分析的目的就是能用自己的方式来灵活实现Toolbar的功能而不需要使用死板的Toolbar控件，这个是在前一篇（ArcGIS.Server.9.2.DotNet实现类似GoogleMap的操作工具条（ADF的Toolbar太丑））的延续寻找更加优雅的解决方法。
根据上面的流程分析要抛开Toolbar控件有2个工作：第一个就是更改脚本端WebForm_DoCallback提交时的目标对象把原先的"Map1"控件改成我们自己的实现了ICallbackEventHandler接口页面或者自己的控件。第二个就是让我们的页面或控件能实现类似Map1控件的载入ServerActionClass类这样的功能。这个只是初步才想法了，具体的实现下一篇在写。
1.ArcGIS.Server.9.2.DotNet的ADF的Toolbar工作过程原理。
开始：
Toolbar工作过程：
一.初始化过程（在页面生成的时候Toolbar控件会生成和它相关的html代码和javascript代码）：
1.根据每一个子Tool生成一个<TD>...</TD>，并且这个TD元素添加onMouseDown、onMouseOver、onMouseOut三个鼠标事件，这样使得TD可以点击执行不同的功能。
2.在javascript中初始化Toolbar1_Items数组，用ToolbarItemObject初始化每一个子Tool添加到Toolbar1_Items数组中。
3.初始化Toolbars数组，用ToolbarObject初始化Toolbar1添加到Toolbars数组中。
4.初始化ToolbarGroups数组，ToolbarGroupObject初始化添加到ToolbarGroups数组。
5.对Toolbar1对象赋一些初始化属性。
二.执行过程（从点击到提交服务端的整个过程）：
1.当Toolbar的Tool被点击时会执行onMouseDown事件的ToolbarMouseDown方法，这个方法定义在ADF的display_toolbar.js中，对于onMouseOver、onMouseOut这2个事件没有实质性的功能是显示效果的切换而已。
2.ToolbarMouseDown方法执行会根据点击的Tool类型进行不同的处理，对于Command和DropDownBox类型的Tool就调用postBack方法直接向服务端进行提交而且对于Tool类型的Tool则根据ClientAction类型调用不同的方法设置地图的操作状态。
3.Tool类型的Tool的ClientAction类型内置了很多如Point、Line、Polyline等根据这个类型会分别调用MapPoint、MapLine、MapPolyline等方法设置地图的操作状态，这些MapPoint方法等是定义在ADF的display_map.js文件中，这些方法执行会调用map对象的setTool的方法设置地图操作状态。
4.设置完地图操作状态就接下来，是进行地图操作了该画点的就画点该画线的就画线了。这些操作是对地图进行操作了那么这些操作代码肯定是在map对象上了，上面的setTool的方法会为map对象的divObject设置onmousedown事件。
5.接着往下执行onmousedown事件调用方法MapMouseDown，这个方法会根据操作类型是结束操作提交结果还是继续设置onmouseup和onmousemove，这个是根据操作类型决定，比如一次性操作的画点到这里就结束操作调用postBack方法向服务端提交结果，而连续操作的画线到这里还需要往下操作就设置onmouseup和onmousemove。
6.最后就执行onmouseup事件的方法MapMouseUp向服务端提交操作结果完成所有动作。
7.上面无论哪种类型的操作殊途同归最终都是需要调用postBack方法向服务端提交结果完成操作，这个postBack方法定义在ADF的display_dotnetadf.js文件中。
8.继续看postBack方法，这个方法执行会调用clientPostBack方法，这个方法是通过eval(callBackFunctionString)方法实现向服务端的提交，跟踪调试可以看到eval(callBackFunctionString)其实就是执行WebForm_DoCallback('Map1',argument,processCallbackResult,context,postBackError,false)这样的方法，到这里一切都明朗了，ADF的类库最终也是通过这种方式像服务端提交数据了，这个和我们自己用Page.ClientScript.GetCallbackEventReference方法产生脚本字符串放在客户端执行一样。
9.现在把ADF产生的WebForm_DoCallback和我们自己用Page.ClientScript.GetCallbackEventReference方法的做一个比较：
ADF: WebForm_DoCallback('Map1',argument,processCallbackResult,context,postBackError,false)
自己：WebForm_DoCallback('__Page',argument,processCallbackResult,context,processCallbackError,true)
10.看上面这2个方法最大的区别就是请求的目标对象不同一个是“Map1”控件一个是“__Page”页面了，由此可见“Map1”控件肯定实现了ICallbackEventHandler的接口
，它能处理ADF脚本方法提交的请求。
11.更进一步，我们在使用Toolbar控件时可以为Tool设置处理的类功能，就是给Tool设置ServerActionAssembly和ServerActionClass属性，这样就说明Map控件还具有一个功能就是能根据发起请求的Tool不同载入我们定义的ServerActionClass类来处理Tool的请求，这样就达到了让用户自己定义Tool的服务端的处理功能。
总结：通过对Toolbar工程流程的分析的目的就是能用自己的方式来灵活实现Toolbar的功能而不需要使用死板的Toolbar控件，这个是在前一篇（ArcGIS.Server.9.2.DotNet实现类似GoogleMap的操作工具条（ADF的Toolbar太丑））的延续寻找更加优雅的解决方法。
根据上面的流程分析要抛开Toolbar控件有2个工作：第一个就是更改脚本端WebForm_DoCallback提交时的目标对象把原先的"Map1"控件改成我们自己的实现了ICallbackEventHandler接口页面或者自己的控件。第二个就是让我们的页面或控件能实现类似Map1控件的载入ServerActionClass类这样的功能。这个只是初步才想法了，具体的实现下一篇在写。
