0hEE9385其实是51#的0hFEFE：

c1 = 0hFEFE
c2 = strconv(c1, 9)
c3 = REPLICATE(c2, 2000)
strtofile(c3, "11.txt"）

只是随便选的一个空白字符。你也可以用0hA1A1的UTF-8，或者，任意可见字符的UTF-8去试，都行！

大佬可能没留意前边的讨论，若采用sych帖子的那个API，ANSI版本，半角空格0h20、全角空格0hA1A1都不行，唯独0hFeFe这个特别的空白字符能够正常计算，很是邪门！
不过，一旦切换至UTF-8领空，任何字符都试过了，尽皆扑街，行字符数目全都返回1或2！

只是随手测试，没有刻意保存、记录，现在还原不了啦。
应该是我代码的问题，可能搞着搞着就给搞乱了！太乱了，代码就不贴了。
之前以为0hA1A1无法正确计算行数，今天一查，可能是行距的问题。
吹版提醒过的：Richtextbox1.text = "xxx"，会冲掉之前的一切设置，结果我不小心给忽略了，弄得乱七八糟。
修正一下：填充0hA1A1跟0hFEFE，效果是一样的。个人推荐用前者，因绝无风险！
至于行数统计，不知是否错觉，当拉大拉小表单，Anchor=15，导致Richtextbox1控件高度改变，半行有可能也会被计入行数。

回到顶楼“1行有几列？”的原始问题。
在UTF-8领空，我遇到了好些莫名其妙的意外状况，挺随机的，也无法复现：
有时会返回1，有时会返回1000（可能因为REPLICATE(0hA1, 1000)填充了1000次的缘故吧）。
退一步想想，其实我的需求，也并非要那么精确，精确到“X列 * Y行 = N个字符”的地步；权衡再三，最终决定放弃治疗，还是用回自己先前不那么精确的“神秘参数”版本罢……

这一次的讨论过程，确实是学到了不少新知识，在此特别感谢吹版和sych二位英雄的精彩展示！
尤其下边这一帖，属实是意外惊喜！——

其实，最初对RichEdit/RichTextbox发生兴趣，还是因为该死的 Markdown。

对于 Markdown，我有一个大胆想法。试考虑这个闭环：

假设日后我们能找到一组相对完美的可逆的双向转换代码库：

RTF --> Markdown
Markdown --> RTF

那么，我们便可以利用 RichEdit 来编辑/显示 Markdown 格式文档了！

让我来分析一下流程：

===============
1、打开一个 .MD 文档；
2、调用“Markdown --> RTF”，将 Markdown 标记转换为 RTF 标记；
3、利用RichEdit，WYSIWYG 编辑此 RTF 文档，以类似 Typora 的方式！而最终用户根本不可能知晓：此时此刻，我们内部编辑处理的，其实是 RTF 标记文档；
4、编辑结束，存档。此时调用“RTF --> Markdown”，将最终文档保存为 .MD 格式。
===============

整个文档编辑、修改的过程，我们的编辑器，根本无需真的去解析、渲染 Markdown 格式文档，一直都处在最古老的 RTF 领空！然而却能够实现近乎完美的 Markdown 实时 WYSIWYG 编辑！

这是最初的构想。

当然，这一切取决于如下必要前提——

在这个星球上，存在一组相对完美的、可逆的“Markdown <--> RTF”双向转换代码库。

可惜目前暂未能找到合适的转换库。Pandoc 据说可以实现双向转换，还是开源的，可惜太大啦，100MB+，且是64位，我试了一个多星期，都无办法将其编译成32位、小于10MB的DLL，以供VFP代码调用。

以上。就是我琢磨 RichEdit 的深层的原因所在啊！

什么“大工程”？哦，明白了，吹版可能误解了。我的意思是：

如果能找到一个DLL库，只需包含这两个函数：MD2RTF 和 RTF2MD，且此二函数可逆；那么，现有的Richtextbox控件，无需任何额外改造，就能够支持在VFP中显示与编辑 Markdown 格式的文档了！
“RTF 《==》 MD”转换的库，大把，网上是现成的啊，只是大多不是C，也不可逆，难以编译成32位DLL而已。
话说，那也只不过私下里随便那么一想，并无什么雄心壮志。

RichEdit是目前仍在维护的古早工程里，实际用到的控件；而这一个行、列计算的遗留Bug，也是一直未得到精确解决方案的实际遗留问题。

[此贴子已经被作者于2025-9-7 17:46编辑过]

程序代码主动地往Richtextbox的客户区堵塞额外字符，讲真，一直都有些心理排斥——主要这样子处理，可能不太安全。

嗯……在表单看不见的负X值区域，复制出一份孖崽，一个不可见的影子控件，反倒是可以为所欲为：反正永远不会影响正常的界面显示，唯，多浪费一份系统资源就是啦。

在影子控件中，可随意加载任意中、英、数字符，这也更贴近实战需求；且，不需[保存/恢复]现场，这也是基于性价比方面考量的一大优势。

故而，这种直接、粗暴的方式，可能是相对合理、方便、快捷的方式。

这星球上，原本最有希望实现“RTF 《==》 MD 双向转换”的代码库，是微软原厂出品的开源的文档转 Markdown 工具“Markitdown”：
https://

结果你猜怎么着？微软似乎自己已放弃了古老的 RTF 格式！微软自己出品的“万能 Markdown 转换工具”，什么阿猫阿狗都能支持，唯独不支持 RTF ！
嘤嘤嘤。

自己写转换代码，难度太大！且，我对于Python几乎是“文盲”。

我曾经“盯”上一个开源代码：
https://
国内访问时常被墙，也不知现在还能否访问？
若能看到先前的简介——意不意外？惊不惊喜？
那其实是我老人家向作者提出的一系列建议。
只可惜收到了最终代码后，用Python编译出DLL，一测试：

完犊子！这东东并不支持中文！

Python的东西，其实至少有80%以上，是你抄我，我抄你的，真正原创转换算法的极少，大多无非拿人家大厂的算法代码，再外边套一层壳，取个漂亮名字，就可以重新放上github了。
最后一封电邮，我不无遗憾地回复：

Since my specific need was for lossless, reversible conversion between the formats, and current solutions inevitably introduce significant discrepancies, I've concluded this approach isn't viable for my use case.

RTF 标记，远比 Markdown 标记复杂，在 RTF 的领空处理 Markdown ，只要严格限定代码可用的格式标记，将其圈牢在最基本、最通用、最常用的若干 Markdown 标记子集以内——理论上，这方案似乎是可行的。

不过，深入接触过 RTF 内部标记后，我们将发现：这种“投机取巧”的可行性，微乎其微。

事关，二者非常难以一一对应，除非微软等大厂出手。

还有，RTF内部字符编码是ANSI，而 Markdown 则是UTF-8，这二者之间的相互转换，可能会有损。

此外，不得不说，RTF标记，其实是一种相当丑陋、臃肿、恶心、落后的标记语言，早该人道毁灭淘汰掉啦！