提示：控件如果放在表单的一个容器里（如：Pageframe,Container等）的时候，左右移动可能会出现计算值非法，原因是mousemove中是按thisform.width计算的位置，这样会出现负值，可以把thisform.width 换成 this.parent.width

这效果确实是超出预期！哈哈！真的很美妙！
不过你仍然低估了ActiveX控件的复杂性。
仔细观察各类应用软件，“分割条”控件一般有两种实现模式：
“贪婪模式”和“非贪婪模式”。
所谓“贪婪模式”，就是你现在采用的方法，将位置、大小的计算与改变，放在MouseMove事件当中；
而比较稳妥的“非贪婪模式”，则是将位置、大小的计算与改变，放在MouseUp事件事件当中。
二者的区别是：MouseMove模式要时刻不停地刷新表单显示，而MouseUp模式只刷新表单一次。

试考虑一下拖动分割条的整个“生存活动周期”：
它始于MouseDown，终于MouseUp；中间过程无论如何拖动，对于所涉及控件的最终位置、大小结果，其实是无意义的。
我不知你是否看明白了我的意思。
在MouseMove事件当中不停地刷新ActiveX控件，这其实类似于数据库的“独占式锁定”：
因ActiveX控件不同于VFP内部控件，它在你拖动过程中，可能无法同步地执行其内部事件的任何代码，尤其是一些耗时的代码，而不得不全世界卡顿下来，一定要等待你拖动完成了，才能继续运作。
此外，还有“分割条”嵌套的问题。
假设表单中有2根左右“分割条”，1根上下“分割条”：
左右两根，表单被分成“左中右”三块；上下1根，将“中”上下切割——整个表单相当于划分为大写的“H”几大区块。
你是无法简单地指望.LockScreen就能处理好这几大块区域刷新的，因在MouseMove模式下，每一小块都迫切需要.LockScreen，才能显示得漂漂亮亮的，而.LockScreen，只有一次宝贵的机会。
我不知你是否看明白了我的意思。
呵呵呵呵。

对付 ActiveX 一般设置： _vfp.AutoYield = .F.   可行不？

不是说了提供的代码不完美吗？
其实不需是否看得明白的文字，只是期待看到更完美的代码。
本人习惯用代码表达思想，并且是可测试运行的代码，极少用文字长篇大论。

纯属个人感觉来说，更喜欢这种拉窗帘的效果。
传统的所谓拖动感觉似搬动

吹版 非常平易近人，面对问题，都是直接给出代码，真的非常敬佩！！

楼主也很热心，非常热心的分享！！

[此贴子已经被作者于2021-12-20 09:39编辑过]

只要表单上放置了若干ActiveX控件，则_vfp.AutoYield = .F.是标配；若默认.t.的话，会随机抛出许多莫名其妙的bug，让人防不胜防、应接不暇。
之所以会用到ActiveX控件，是因为要在表单中显示东南亚字符，比方说泰文、印度文之类。
详见这一帖别人的代码（不要再揶揄我不贴代码啰，呵呵呵呵）：
https://www.

当分割线放在页签里，并移动了分割线，在切换页签回来后，分割线的位置又恢复默认位置了，这是什么原理呢？

是不是 pageX.activate里初始了分割条？如果是的话切换回来后就会重新初始化，所以会恢复到初始位置

楼主很用心