提示:控件如果放在表单的一个容器里(如:Pageframe,Container等)的时候,左右移动可能会出现计算值非法,原因是mousemove中是按thisform.width计算的位置,这样会出现负值,可以把thisform.width 换成 this.parent.width
以下是引用吹水佬在2021-12-18 18:02:48的发言:
操作未见异常,这样的效果可以了。
操作未见异常,这样的效果可以了。
这效果确实是超出预期!哈哈!真的很美妙!
不过你仍然低估了ActiveX控件的复杂性。
仔细观察各类应用软件,“分割条”控件一般有两种实现模式:
“贪婪模式”和“非贪婪模式”。
所谓“贪婪模式”,就是你现在采用的方法,将位置、大小的计算与改变,放在MouseMove事件当中;
而比较稳妥的“非贪婪模式”,则是将位置、大小的计算与改变,放在MouseUp事件事件当中。
二者的区别是:MouseMove模式要时刻不停地刷新表单显示,而MouseUp模式只刷新表单一次。
试考虑一下拖动分割条的整个“生存活动周期”:
它始于MouseDown,终于MouseUp;中间过程无论如何拖动,对于所涉及控件的最终位置、大小结果,其实是无意义的。
我不知你是否看明白了我的意思。
在MouseMove事件当中不停地刷新ActiveX控件,这其实类似于数据库的“独占式锁定”:
因ActiveX控件不同于VFP内部控件,它在你拖动过程中,可能无法同步地执行其内部事件的任何代码,尤其是一些耗时的代码,而不得不全世界卡顿下来,一定要等待你拖动完成了,才能继续运作。
此外,还有“分割条”嵌套的问题。
假设表单中有2根左右“分割条”,1根上下“分割条”:
左右两根,表单被分成“左中右”三块;上下1根,将“中”上下切割——整个表单相当于划分为大写的“H”几大区块。
你是无法简单地指望.LockScreen就能处理好这几大块区域刷新的,因在MouseMove模式下,每一小块都迫切需要.LockScreen,才能显示得漂漂亮亮的,而.LockScreen,只有一次宝贵的机会。
我不知你是否看明白了我的意思。
呵呵呵呵。