Editing more than 64K of text

[kolbe]

I'd like to create a text editor on the device that is able to display and edit large text files... in the megabyte range.

As has been mentioned many times in the forum, the textbox object can only display 64K of text. Any ideas on how to get around this? I could display chunks of text at a time but that makes scroll bar behavior odd because every time I'd go from the end of a chunk to the beginning of a new one, the scroll bar would jump from the bottom to the top. Plus I don't know of a way to detect the position of the scrollbar in a textbox. You know the cursor position but you don't know how the user is scrolling the textbox. The html libraries out there allow larger files but they are not really for editing.

Am I missing the obvious? Shouldn't seem like this should be hard to do.

Thanks

 

[Ariel_Z]

Hi,
This may be a bit difficult.
To get started, what you can do is separate the different parts of the control. In this case, you should separate it into a scrollbar, a textbox and the text itself.
You can store the text in a string array (or arraylist), and display only the needed portion. Then, you need to manually handle scrolling -calculate the right size of the scroll bar, the amount of text to be scrolled each time and so on. You will have to place more text on the textbox than actually visible, so that some original scrolling ability will be kept, allowing you to add text on the direction of scroll, delete text on the opposite direction, handle the currently displayed line (as when your delete from the beginning it will probably scroll automatically) and hide the original scrollbar. The issue of adding text and deleting it in the background is complicated and should be thought into deep details. For example, you wouldn't like the interface to hang when you scroll fast, so you might need to do some threading operations.

I would recommend that you limit the development version to a small limit of text (for example 300 lines) so that you can test it more easily.

 

[Erel]

Can't you divide the text and use a TabControl or something similar?
I don't think that a user will be able to handle such huge textbox. How will he find the interesting parts?

 

[kolbe]

Hi,
This may be a bit difficult.

I was afraid someone would say something like this but no worries. I'm in no big hurry with this one.

The issue of adding text and deleting it in the background is complicated and should be thought into deep details. For example, you wouldn't like the interface to hang when you scroll fast, so you might need to do some threading operations.

I think this will be the most challenging part, keeping up with unpredictable scrolling. It's a good excuse to get acquainted with the threading operations. Thinking about using the stringbuilder functions in the StringEx library as well.

Thanks for the ideas.

 

[kolbe]

Can't you divide the text and use a TabControl or something similar?
I don't think that a user will be able to handle such huge textbox. How will he find the interesting parts?

Ok the full idea. The idea behind this is to be able to edit html pages for use with the Tomeraider compiler. So integral to this project is a nice find/replace function using the regex library to add and remove formatting as needed. Generally I will need to append multiple files together as well. The result is often in the megabytes or even tens of megabytes. So the idea isn't so much scrolling to find things or to read but doing searches and editing.

In the past I've used trusty old VIM. Even used an emulated MSDOS version of VIM on the PPC a few times.

 

[Ariel_Z]

In that case, why do you need to show the text at all? Use an array of strings and operate on them. You will anyway not be able to treat all the text as one string.

 

[kolbe]

In that case, why do you need to show the text at all? Use an array of strings and operate on them. You will anyway not be able to treat all the text as one string.

In regards to the scrolling above, you have a point, but many times these docs are not consistent in format and the search replace pattern doesn't work in all the cases that it should. I will need to look at the changes made to the text.

Is there a limit to string size? Is it memory related?

 

[Ariel_Z]

The theoretical limit is 2G byte which are about 1Gb characters. But you are not likely to reach this limit or anything near. I guess your device will start to behave strange when if you try.

 

[RandomCoder]

Have you considered displaying just enough text to fill the textbox without using scrollbars. Then use previous/next page buttons and load in the required text. Maybe this would be easier to achieve?

Regards,
RandomCoder

 

[mjcoon]

If we are talking of continuous text that has to be word-wrapped to show in a text box then determining how much is visible, starting at any given point, requires tricky computation of variable width font and knowing how the line-break algorithm works. Or perhaps reading it back out of the text box...

Mike.

 

[RandomCoder]

I was thinking along the lines of using a fixed width font and determining how many bytes a textbox can hold. Then just read x bytes at a time into the textbox. Come to think about it, it doesn't matter if scroll bars are displayed, just so long as you don't exceed the limit of the text box. The difficult part would be avoiding spilting words but to do that I guess you would just check that the character was either a space or carraige return etc.

Regards,
RandomCoder

 

[kolbe]

Thanks for all the ideas.

What I have so far is that I display 40 lines of text at a time. By line I mean until a CRLF. So unless the 40 lines are more than 64K I'll be ok. Then using the door library I've hidden the scrollbar and am using my own that is based on the size of the entire file. When scrolled the appropriate lines are displayed. Scrolling behavior is a bit atypical but it works. I need to work out better when to refill the textbox based on not just the scrollbar but also cursor movement and how to calculate where to put the cursor after a refill as to have better continuity.

So far I've managed to load and edit an 8 meg file. The entire file is loaded into an arraylist. Doing it this way there is negligible speed difference compared to that of a normal scrollbar. At some point I might resort to editing straight from a file but I'll have to see how responsive it is.

 

[Ariel_Z]

For very large files you'll have to cache it. So that you read say up to 1MB to the arraylist, and read from the file the direction you need. Textfiles, being serial-readed, are difficult for this purpose - codider breaking big file into some small and one data file that will keep details about which file contains which part of the text.