发现这个冲突已经很久，一直没想到解决的方法。而这个博客里也存在这一点点的冲突。
因为Web.UI.Countrols里的几个控件都用到了AutoPostBack，而它所实现的机制其实就是在客户端修改一些数据后提交表单，而这样却给页面的一些事件逻辑带来了混乱。
首先，它的提交是无条件的。例如:toolbar他tooltrip的事件处理，如果查看它所生成的HTML代码，总可以看到这样的内容：
而在这些控件上会有这样的代码：onSelectedIndexChange="JScript:document.Form1.__Inc_ClientLfetMenu1_TabStrip1_State__.value=event.index;
if (getAttribute('_submitting') != 'true'){setAttribute('_submitting','true');try{__doPostBack('Inc_ClientLfetMenu1$TabStrip1','');}catch(e){setAttribute('_submitting','false');}}"
onwcready="JScript:try{document.Form1.__Inc_ClientLfetMenu1_TabStrip1_State__.value=selectedIndex}catch(e){}"
这样就使页面的一些认证失败。当然这并不会带来什么问题，因为一般用这些控件来处理事件的时候就是让用户导航到另一个页面，而且可以不带参数的，所以当然也可以不用验证用户的当前页面是否正确的。简单一点，就是说用户放弃了前面页面的操作，进入其它页面里去。
然而这样无验证的提交却给上传文件带来了一个问题。就是它总可以提交已经选定的文件。我试图用reset表单来清理已经选择的文件，但这样只对我所设定的事件有效，对web.UI.Controls无效。我还试过在form的onsubmit上处理文件清理，但还是不行，也就是说Web.UI.Controls的事件跳过了form的onsubmit事件。这让我很郁闷，。。。
相反的，还会存在另一个问题。并不是Web.UI.Controls所产生的，而是asp.net的客户端验证的冲突，就是多余的验证。例如当我选择了修改密码，而后又不想修改的时候，就直接点击linkbutton想导航到其它页面，但这时的验证还是要我必须输入密码，而不能放弃修改。当然，这时候利用web.UI.controls的事件无效性，可以直接跳过它，呵呵，不知道是好事还是坏事。。。。。。
最后还是要解决在文件上传时的问题，因为上传的文件可能会很大，如果用户已经放弃了上传而还要把文件传到服务器上的话，这是一个很不必须的事情，虽然只是存放在临时文件夹里，但这样的长时间等待及数据处理都是一种浪费。。。。。。。。偶然的机会，想到了用iframe来处理它，这是一个好方法，这也是为什么很多网站都用iframe来处理上传文件的原因之一吧。不管怎样，这都是个好方法，而应该注意的是，它的权限验证。本博客里的inframe里的独立页面在单独取出的时候出现一个小错误，应该是数据没有传过去。当然，如果直接给出信息，不能直接调用该页面可能会更好。。。