给Winform中的TabControl添加更现代的拖拽功能

  • A+
所属分类:.NET技术
摘要

  上周接到一个开发任务,大致是允许APP中的Tab拖动以成为一个独立Tab,脱离之前的TabControl,就是现在Web拖动标签页创建新窗口的功能,现在浏览器必备的功能,应该很简单,然而我司采用的Dotnetbar框架中的TabControl关于拖拽操作并没有提供多少改造的余地,我顿时想起了当年高中装个Win7测试版也可自称geek的年代,那时候摆弄完系统也得和群里的大佬讨论什么浏览器才配得上geek的我,就是那时候发现IE没有支持拖动标签页,双击标签页等一些其他浏览器早就具备的功能,如今不觉有几分宿命感。

  上周接到一个开发任务,大致是允许APP中的Tab拖动以成为一个独立Tab,脱离之前的TabControl,就是现在Web拖动标签页创建新窗口的功能,现在浏览器必备的功能,应该很简单,然而我司采用的Dotnetbar框架中的TabControl关于拖拽操作并没有提供多少改造的余地,我顿时想起了当年高中装个Win7测试版也可自称geek的年代,那时候摆弄完系统也得和群里的大佬讨论什么浏览器才配得上geek的我,就是那时候发现IE没有支持拖动标签页,双击标签页等一些其他浏览器早就具备的功能,如今不觉有几分宿命感。

  话又说回来,新功能需要配套同系统下多款软件,以我目前的权限不可能对原界面进行重构,所以还是得在现有的界面下实现该功能,在实际工作中我将其改为了通过右键菜单实现该功能,然而我现在要在实现原理上,推演一下如何在TabControl上实现真正的拖拽独立Tab功能。

  其实在我将其改为右键菜单实现之前,我已经将原定的拖拽功能初步实现,但在考虑过后还是改为前者。原理上都是一样的,将选定的Tab放到一个供独立展示且可拖动的TabControl中,然后把原来的Tab dispose掉。导致我放弃通过拖拽实现的原因,一是我司采用的TabControl对Tab的操作只提供了多个Tab存在时,前后插入判断的反馈;二是Tab不能跨越属于自己的TabControl,放到另一个TabControl中去,这样就使得拖拽的用处更加鸡肋,通过拖拽使之独立,亦要拖拽使之还原,结合第一点,更涉及到新TabControl中的Tab归属判断和割离,工作量估计不止翻倍,开了这个口子,指不定要拖些什么幺蛾子......

  又扯远了,通过拖拽实现需要克服的是第一点,由于这个原因,我们只能自己定制一套反馈判断,我们假定拖拽一定距离后便判定为需要new control,首先要判断用户开始拖拽,要用到MouseDown,然后在这个状态下计算鼠标移动距离,满足距离条件后即可new,亦或者松开鼠标即MouseUp之后new,当然,不论什么时候new,new完之后要记得break,因为我们只需要一个Tab页面就可以了,最后如果要实现Tab合并或者归位,则要计算移动至一定量的重叠区域即可,遗憾的是由于我上文所述的两点,实现合并操作所需要的工作量是可以预见的,如果有人要实操一下,我建议在MouseDown之时,以Mouseposition上划分一块Tab标签同样大小的区域,方便之后的重叠区域和相关判定计算。

  关于供以独立TabControl拖动的容器选择也值得讨论,我曾在新窗口和Bar之间犹豫,最终选择了Bar,dotnetbar.Bar这个控件非常好用,就是内部结构有一点复杂,网上也有相关文章,我就不赘述了,本考虑通过Bar的特性来实现Tab的拖拽合并操作,但还是之前说的,Tab本身不支持在不同TabControl之间跨越合并,这一点极大地限制了拖拽功能的后续开发,指不定当初IE迟迟不更新标签页的相关操作就是因为这个原因,笑。