harold aptroot wrote:

Is this style cancer?

No. Linq has both it's Pro's and Con's. However, there is a clear benefit: Easy to write and easy to read (keep in mind that, if using Visual Studio, you have full intellisense support. And you can use your favourite code template, too.)

someStuff.Where(c => c != What).Select(d => d + The).Foreach(e => Hell(e));

looks better to me than

List tmpStuffList = new List();
for (int i = 0; i < someStuff.Count - 1; i++)
{
if (someStuff[i] != What)
{
tmpStuffList.Add(someStuff[i]);
}
}

for (int n = 0; n < tmpStuffList.Count - 1; n++)
{
Hell(tmpStuffList[n]);
}

I'll stick to the LinQ way of Querying. ;)

I guess I go with the approximation approach, that sounds kind of reasonable.

Hi Richard, thanks for your comment. I've heard of MMF, but haven't used it before. Sounds interesting, although that wouldn't solve the scrolling part. And thanks for the hint in terms of an article. I might consider that, why not. :)

Hi, thanks for your thoughts on that. When splitting up into edible volumes, how would you handle selections across the volumes? To put things straight - it's not about solving an actual problem. Some time ago, I worked with databases. There is nothing more frustrating than dumping a large MySQL database, just to realize after some hours, that the "CREATE TABLE" statement has been added to the export. Just as an example I've in my mind now. But there is no customer request behind that. It's just an idea, stuck in my head for a few months now, which I'd like to solve. What I've got so far: If you use the text approach, chunking would be the best option. There is no need to split the files on the drive, but you would need some kind of controller which would manage the changes being made, map them to the chunks and save them if necessary. This would require paging for navigation, because scrolling would simply be to difficult if you need to take the window size and linebreaks etc. into account. If I want scrolling, I should take the Hex-Editor approach, that is: Set the textfield to a fixed amount of characters per line, and don't care for linebreaks, etc. I'm still open for more ideas, though. :)

Not really, at least for Windows. On the one hand, there is Large Text File Viewer, but that is hard to find at the moment. EmEditor is commercial Software, but disables word wrapping and some other options, afaik. And I don't think editing will work. Then, there is HxD, a Hexeditor. It can even read your disk. That would be the last option, cause with a hex editor, you dont have to deal with line breaks etc. Everything can be set to fixed with. But that would be too easy.^^ A little bit easier to approach would be paging, I guess, instead of scrolling. But that is not so nice, but would be an Option, too.

Hi folks, for some weeks now, I'm getting my head around an interesting problem: I'd like to display a text file of several gigs, and let it be editable. Now - how would you do that? All standard approaches fail, because they rely on the file being fully loaded into RAM, which is impossible with several gigabytes of data. So, I thought I'll create a CustomControl. Basically, I've derived a Control from the Control class, which embeds a FrameworkElement in it's Generic.xaml. This FrameworkElement has a VisualCollection. Now, I hand over a Stream to this control. The Stream must be seekable and writable, otherwise you will encounter an exception. So far, I do the following: I read a chunk of data from the Stream, draw that using FormattedText on a DrawingContext, retrieved by a DrawingVisual. For scrolling, I simply adjust the offset of the FormattedText-function. To achieve seamless scrolling (which is needed, so you can scroll from one buffer chunk to the next without a visible gap), I have a function which calculates the amount of text that fits precisely into a rectangle (e.g. the Window's viewport), so that the rest of the current buffer, together with the next buffer, can be printed on the next rectangle. But, for the sake of it, I can't find out how I would do standard editing functionality. Because, for the scrollbar and this "chunking" to work, one needs to precompute the needed amount of text to fill the rectangle, which changes when editing the text. tl;dr: Do you have a smart concept on hand, together with WPF and C#, to create a TextEditor, which is capable of editing gigabytes of text?