Hi. I'm developing an IDE for fasm (for 32 bit UEFI environment). The IDE is based on my library that provides Text User Interface using EFI console input/output functions. My main concern now is multiline text edition fields. What is done:
- Output of the visible portion to the screen (according to control's width and height.)
- Navigation (Ctrl+Home, Ctrl+End, Home, End, PgUp, PgDn, Up, Down, Left, Right, Ctrl+LeftArrow, Ctrl+RightArrow).
- Selection (all of the above when holding any of the Shift keys adjusts selection -- selection appears and disappears according to user actions)
- Caret show/hide (hidden when the text field is not focused or when there is a valid selection, otherwise shown).
- Scrolls (both vertical and horizontal).

What is to do now:
- Everything else.

Usage notes:
The multiline edit control that I'm implementing is part of Controls collection (besides Label, CheckBox, ComboBox, ListBox, PushButton, which are complete and perfectly working now). Controls have to belong to a window. A window may contain any number of controls in any order.
Only one control can be focused at any moment of time. Focus is moved either with TAB / Shift+Tab keys, or with Left/Right/Up/Down arrows when a focused control doesn't have any more items in this direction. Focus can also be moved by Enter key (the default event handler selects item and moves focus to next control, if not intercepted by custom event handler -- Like default and custom Window Precedures in MS Windows).

Memory allocation:
'CreateWindow' allocates a pool from system memory, copies window attributes there and stores the address in [ActiveWindow] variable of the main program. It also draws window border (none, solid, single line or double line), shadow (if needed), shows window caption paints the window with the specified colors. When a child window is created and then destroyed, the focus and the screen contents 'under' the child window are automatically restored. When the main window is destroyed, the program exits.
'DestroyWindow' releases memory allocated for this window and all controls within it, restores screen contents and passes control to parent window. If no such, then exits.
'CreateControl' allocates a pool from system memory, large enough to contain control Header structore and right after it, all its items in one contiguous array. Items are stored like an array of pointers, which point to strings with item contents. An item actually consists of one string. A string is a WORD that contains its length and an array of WORDs for the characters. Well, I feel like I can use the high-order byte of Length as MaxAllowedLength because I'm not up to process lines longer than 256 characters, but I'm still thinking.

Questions:
1. Did I forget something? Literally anything: key combos not related to editing, other control types that I definitely need, etc.

2. For text edition fields, I need a memory reserve to hold additional strings that the user will type during edition process. How many lines will suffice in your opinion? 32? 64? Will 1024 be enough?

1024 32-bit pointers will take 4096 bytes, it's not that much I think. But I'm really puzzled about how to store dynamically changing string contents. I'm trying to decide between allocating memory for each item separately or allocating one big pool (about 1M probably) and handling item contents within it manually. I need to write a manual mini-heap driver in this case.

That all topped up with Undo-Redo-thing, I feel sort of puzzled.

Any ideas and suggestions are welcome. What do you think?

The code and the executable file are here, publically available:
https://yadi.sk/d/FmkMVKd4zfhVZ
P.S. Click the flag at the bottom to switch interface from Russian to English
P.P.S. No Warranty!

Allow for as many lines as the memory can hold. Is there a reason to limit it to only a certain amount?

Thanks revolution. Yes, there is a reason. Maybe it's only in my head tho.

Memory allocation that concerns interface resides in interface library which can be used by all sorts of programs as it only handles interface (forms and controls). A client program that may use it (not necessarily an IDE like the one I'm developing) must not be limited in any way more than needed.

In my interface library, I allow client program (IDE or anything else) to have multiple independent text edit fields in one window. The client program can create child windows with their own control sets. The client program will also consume memory (apart from interface needs). So if I take all the memory for the needs of one multiline edition field, that will spoil the game of others.

I'm thinking of dynamical reallocation of controls when some kind of limit is reached so eventually, theoretically, files up to 'AvailableMemoryAmount' size can be opened. But as a starting point, I think I need rather humble amount of memory overhead for possible changes to initial content of the field.

I think it would be better to allocate on demand. As the user types more information then allocate more memory. If the user deletes information then deallocate memory. If you have a mechanism for defragmenting memory regions then even better, or just use the paging mechanism as a poor-man's-defragmentor.

MrFox please compile to execute file your editor and give executable file !
I try compile your code in fasm 1.69 but get many errors !

Roman, post #2 contains the link where you can download the code and the executable file. The exec is .efi and the source is .asm and .inc files. Pay attention that this is a 32bit version.

Revolution, yes. That's what I'm thinking about. I incline to my own defragmenter version.

And how did i run efi file ?

I first time see format efi !

And why so hard ? Why not simple exe file ?!
Why need use efi file ?!

EFI files run in UEFI environment. It is a modern version of BIOS. You can't run them in any OS, only UEFI.