Thisform.Richtexbox1.ScrollBars = 0

只是在计算行、列字数时，一直存在误差（其实这本身也正常的：一个回车右边就会少很多字，一个纯空行能少更多！若真要逐字符地抠字数，似乎也无必要！），计算时会主动地一屏减掉了一些字符数目。

51#和86#两位英雄的代码，都行啊！

造谣！那是两位英雄精心调配的得意佳作！我老人家读了都真心景仰的！
你要将代码中的对象名改为自己表单中的实际名称，倘若一字不漏地照抄，那当然得出错！

依我的理解，MD 是一种“轻量级”、“微量级”的格式标记，介于 TXT 与 HTML/RTF 之间，且更偏向于 TXT。MD 同时具备了 TXT 与 HTML 的一切优点，且无后者的复杂臃肿，是一种相当完美的现代格式文档。

至于编辑、预览 MD，我却不想花费太大精力；若无法简单实现，则直接放弃可也。毕竟，径直用Editbox或RichtextBox 显示 MD 源文档都行—— MD 不像 HTML/RTF，它的那些简单标记，即便不作任何渲染，也是完全可读的。

俗话说：又想马儿快快跑，又想马儿不吃草——没错儿，这说的正是我老人家！

因为一直琢磨的都是“MD <==> RTF”之间的可逆转换，倘若用VFP原生替换函数去手动处理，必然涉及到RTF标记的解析，而这绝对是一道鸿沟！
——事关，RTF太TM复杂、太TM臃肿啦！
网上其实有现成的RTF解析的C代码，然而，从最底层一步一步解析RTF，那绝非普通人能玩得转的。

更多的，则是参照Pandoc的做法，将整个转换过程，分割成3大块：
① From -> ② 转换 -> ③ TO
其中，①和③支持一大堆杂七杂八的格式，而②是相对独立的转换模块。
如此一来，我们根本无法简单地抽取出所需模块：
① From MD -> ② 转换 -> ③ TO RTF
① From RTF -> ② 转换 -> ③ TO MD
它打了一个大包，千头万绪的，没人能从中切分出一小块蛋糕来。

难！——就一个字。

大佬啊，这两行代码，表面上好用，实战可能会有(大)麻烦！
今天晕头晕脑地调试了整整一天，Richtextbox表现一直很不正常，随机性地抛出异常。
经常性地表现为：
在 Lock/UnLock 代码之后，Richtextbox可能无法以代码激活，呈现灰色，需手动点击一次才能够唤醒。
一开始一直以为是某个深藏不露的逻辑错误，拼命地Debug，拼命地查错，一直无办法解决……直至晚上10点，一拍脑门，这才想起来！——注释掉了这一组 Lock/UnLock 后，整个世界一下子豁然清朗了！
原来是它们搞的鬼哇！
吐血！
慎用！慎用！慎用！
——说三遍。

确实很可能是Redraw的问题。
你这么一说，我想起来啦：
许多年以前，我们曾套用网上的开源 VB6 代码，编译出一个 Richtextbox 的替代品，以便更好地支持Unicode。VB6 的代码，说实话，仅限于“勉强看懂”水平，修修补补，根据自己需求定制一下个别方法函数，勉强倒也还凑合；若正儿八经拿 VB6 去写控件，那做不到！那控件同样也有这个Redraw问题：绝对不能改Visible！一改，就变成了僵尸，无论如何再也唤不醒了！
当时我们自己实在没能力修复这个Bug，无人精通 VB6。最后想出来的解决办法比较搞笑：
若需 .Visible = .F. ，就设置：
with this
    .left = 1
    .top = 1
    .width = 1
    .height = 1
endwith
理论上，应该不会有人能留意到，在窗口左上角有个小黑点——那是一片海，一个世界！

总结一下：
自己编写可视化控件，有可能会遇到无数奇奇怪怪、匪夷所思的Bug，你根本想都想不到的，故而上次你一晚上弄一组控件出来，问“有没有搞头”？——当然有搞头！不过——重点是这个“不过”——事情恐怕没那么简单。
讲真，很鬼复杂滴！