Text Management in Memory (looking for a fast proper design)

[Rainstorm]

hi

I'm looking for a way to efficiently handle text in Memory that is being edited etc in a window.

I've written just a few of the very basic keyboard operations, & since how i store & access the text in Memory is gonna affect the coding of these routines..I want to settle down into the best way of doing this.. since am in the process of coding this stuff presently.

There seems to be some inefficiency in some areas..with the present model am using.

While coding some of the operations.. I realised ..that for example everytime there is a text insertion
I need to move all the text in the buffer ahead till the end of the file, similarly for delete....move all the text back by 1. For large files this seems inefficient.. & also imbalanced,.. in that editing done in the beginning of a large file will be moving a lot of data compared to the end of the file.

This is what am presently doing
------------------------------------------
- I have a textbuffer with all the  text data
- Another buffer with Dword sized elements containing the charcount of each of the lines

I basically modify these buffers, with editing operations accordingly & use the the line lengths buffer
to help with the various operations.

one thing would be to keep a buffer for each line.. but that sounds.... ridiculous & not very practical
so that would take away the overhead of the insert/delete operations.

I just want to first arrive at the fastest (& most stable) design....before going on.... as this would affect the coding of the various text manipulation operations.. - or I'd have to keep coming back & editing them.

Any Ideas, suggestions or tips would be greatly appreciated.

Thank You
-

[jj2007]

one thing would be to keep a buffer for each line.. but that sounds.... ridiculous & not very practical

Why ridiculous? Have a look at the array routines that Hutch introduced in the new beta. Another option is to keep only the portion that is visible in a window in a small fast segment, to be updated (inserted etc.) only when scrolling is needed.
In any case, even if you choose the brute force design, you will see a measurable delay only for very large text.

[Rainstorm]

Why ridiculous? Have a look at the array routines that Hutch introduced in the new beta.

thx for shedding some light on that, just didn't have a clue on how feasable that would be for a large file.

Another option is to keep only the portion that is visible in a window in a small fast segment, to be updated (inserted etc.) only when scrolling is needed.

dunno if am getting it right..but i'll have to consolidate this segment with my main txtbuffer after a scroll..so the insert/delete overhead would still be there

--

[raymond]

I would have to assume that you are reluctant to use Windows API functions. Otherwise you would do that work in a RichEdit control (or even a multi-line simple edit control) which would take care of all the text movement.

And, unless you are using your computer for serious multitasking aiming for CPU usage as close as possible to 100% efficiency 100% of the time, instruction timings (or the use of inefficient Windows APIs) should not be too much of a concern... a person typing 1000 words per second is not yet born.

[Rainstorm]

And, unless you are using your computer for serious multitasking aiming for CPU usage as close as possible to 100% efficiency 100% of the time, instruction timings (or the use of inefficient Windows APIs) should not be too much of a concern... a person typing 1000 words per second is not yet born.

have no experience with this.. & thought.. that for real large files..  it might get slow, thanks for giving some perspective on the whole thing. - if i was looking for a good design though.. would there be any that you recommend.. ? - also taking into account other things like 'undo' etc

I would have to assume that you are reluctant to use Windows API functions. Otherwise you would do that work in a RichEdit control (or even a multi-line simple edit control) which would take care of all the text movement.

I started off just writing it,..so since am some way into it... I might as well continue & write it without the control - i'd probably learn something along too.

Since that came up...by way customizability, would writing it like i am now.. offer an advantage.. over using a control  - like i can make it how i want & would allow more freedom to add features etc ?

thanks
-

[jj2007]

Since that came up...by way customizability, would writing it like i am now.. offer an advantage.. over using a control  - like i can make it how i want & would allow more freedom to add features etc ?

Good luck! Have a look at the long list of functions offered by the RichEd dll... even when using the predefined features, there is enough to learn - just have a look at the GeneSys editor thread ;-)