richTextBox 字符数限制?
我在将大量文本存储在丰富的文本框中时遇到问题。
我正在尝试读取一个相当大的文本文件(从 90mb 到 450mb 的任意位置),并将我读到的内容放入富文本框中。 它可以在一个简单的程序中运行,但是当我在一个复杂的程序中运行时,我会得到一个 OutOfMemory 异常。
需要注意的一件事是,当我退出我的简单程序时,我在程序返回 0 之前收到 OutOfMemory 异常。
这是我的简单程序的代码:
array<String^>^ strArray;
StreamReader^ sr;
String^ dummyStr;
int dummyInt;
sr = gcnew StreamReader("C:\\testsize.txt");
while( (dummyStr = sr->ReadLine() )!= nullptr)
{
dummyInt++;
}
sr->Close();
sr = gcnew StreamReader("C:\\testsize.txt");
strArray = gcnew array<String^>( dummyInt );
for(int i=0; i < strArray->Length; i++)
{
strArray[i] = sr->ReadLine();
}
richTextBox1->Lines = strArray;
我的项目中有一个类似的代码片段,当我执行 richTextBox1->Lines = strArray 行。
我已经阅读了富文本框的文档,它说最大限制是 64KB 的字符,但这在中途是有意义的,因为我可以加载文本,但我猜程序在之后转储它时出现问题。
有任何想法吗? 我一直在尝试寻找一些没有限制的自定义控件,但到目前为止还没有成功。
I'm having a problem with storing amazing amounts of text in a rich TextBox.
I'm trying to read a text file fairly big( anywhere from 90mb to 450mb), and put what I've read in a rich textbox. It works in a simple program, but when I do in a complicated program I get an OutOfMemory exception.
One thing to note is that when I exit my simple program, I get an OutOfMemory exception right before the program returns 0.
Here is my simple program's code:
array<String^>^ strArray;
StreamReader^ sr;
String^ dummyStr;
int dummyInt;
sr = gcnew StreamReader("C:\\testsize.txt");
while( (dummyStr = sr->ReadLine() )!= nullptr)
{
dummyInt++;
}
sr->Close();
sr = gcnew StreamReader("C:\\testsize.txt");
strArray = gcnew array<String^>( dummyInt );
for(int i=0; i < strArray->Length; i++)
{
strArray[i] = sr->ReadLine();
}
richTextBox1->Lines = strArray;
I have a similar snippet of code in my project, and the exception pops up when I do the richTextBox1->Lines = strArray line.
I have read the documentation of the rich textbox, and it says the max limit is 64KB worth of characters, but that makes sense halfway through, as I can load the text, but I guess the program has a problem dumping it afterwards.
Any ideas? I have been trying to find maybe some custom controls without a limit, but to no success so far.
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(1)
至于将大量文本转储到丰富的编辑中,这通常会非常慢,以记事本为例,尝试用它打开一个 2MB 的文件。 我认为更高级的文本编辑器处理这些的方式是通过“虚拟控件”,我知道这些通常与列表控件一起使用,我也会考虑与文本框一起使用。 它们的行为/功能基本上与您正常的日常控制相同,但无需尝试一次渲染大量文本,它们具有“屏幕空间外”的虚拟空间。
至于您的内存不足问题...我很困惑您说当您尝试将文本转储到示例代码的最后一行时发生错误。 您还提到限制是 64KB,所以现在假设您的文件像您所说的那样巨大...您尝试将超过 64KB 的文本转储到 64KB 限制框中时出现错误是有道理的。 我错过了什么吗?
编辑我重新阅读了一些问题,我看到你现在在问什么,所以在简单的程序中,当所有内容加载完成后,当程序退出时,你会收到一个错误。 将调试点放入析构函数中,并准确查看此错误发生的位置。
编辑2 现在我知道你在什么系统上,我去看了一下,文档比64K限制稍微复杂一点。 首先,这不是指 64 KB,而是指 64000 个字符。 另请注意,您可以根据需要更改此限制。 其次,如果您使用 SF_TEXT 而不是 SF_RTF 进行流式传输,则此限制没有任何影响,我想这就是 .NET 接口背后所发生的情况。
As far as dumping a huge amount of text into a rich edit, this usually is going to be excruciatingly slow, take notepad for example, try and open a 2MB file with it. I think the way more advanced text editors deal with these is by a 'virtual control' I know these are often used with list controls, and I would think with text boxes as well. They basically act/function the same way as your normal everyday control but without trying to render oodles of text at a time, they have virtual space 'off the screen space'.
As far as your out of memory issue... I'm confused you say the error happens at the last line of your sample code when you try and dump your text to it. You also mention that the limit is 64KB so now assuming your file is huge like you say... it makes sense you get an error there you've tried to dump more than 64KB text into a 64KB limited box. Am I missing something?
Edit I reread some of the question I see what you are asking now, so in the simple program you get an error after everything is loaded done, when the program exits. Throw a debug point into your destructors, and see exactly where this error happens.
Edit 2 Now that I know what system you are on, I went and had a look, the documentation is a little more complex than 64K limit. Which first of all isn't referring to 64 KB but rather 64000 characters. Also note that you can change this limit as you please. Secondly if you are streaming with SF_TEXT and not SF_RTF this limit has no effect, which I would imagine is what is going on behind the seen of the .NET interface.