flat assembler
Message board for the users of flat assembler.
 Home   FAQ   Search   Register 
 Profile   Log in to check your private messages   Log in 
flat assembler > IDE Development > Fasm IDE EFI Text Editor questions

Author
Thread Post new topic Reply to topic
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
Fasm IDE EFI Text Editor questions
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?


Last edited by MrFox on 28 Nov 2016, 13:02; edited 1 time in total
Post 28 Nov 2016, 12:34
View user's profile Send private message Reply with quote
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
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!


Last edited by MrFox on 24 Dec 2016, 08:19; edited 1 time in total
Post 28 Nov 2016, 12:40
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14610
Location: Planet Dirt
Re: Fasm IDE EFI Text Editor questions

MrFox wrote:
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?

Allow for as many lines as the memory can hold. Is there a reason to limit it to only a certain amount?
Post 28 Nov 2016, 12:46
View user's profile Send private message Visit poster's website Reply with quote
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
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.
Post 28 Nov 2016, 12:56
View user's profile Send private message Reply with quote
revolution
When all else fails, read the source


Joined: 24 Aug 2004
Posts: 14610
Location: Planet Dirt
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.
Post 29 Nov 2016, 12:12
View user's profile Send private message Visit poster's website Reply with quote
Roman



Joined: 21 Apr 2012
Posts: 323
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 !
Post 29 Nov 2016, 12:36
View user's profile Send private message Reply with quote
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
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.


Last edited by MrFox on 29 Nov 2016, 14:29; edited 1 time in total
Post 29 Nov 2016, 14:22
View user's profile Send private message Reply with quote
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
Revolution, yes. That's what I'm thinking about. I incline to my own defragmenter version.
Post 29 Nov 2016, 14:26
View user's profile Send private message Reply with quote
Roman



Joined: 21 Apr 2012
Posts: 323
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 ?!
Post 29 Nov 2016, 14:46
View user's profile Send private message Reply with quote
MrFox



Joined: 17 Aug 2016
Posts: 52
Location: Russia
EFI files run in UEFI environment. It is a modern version of BIOS. You can't run them in any OS, only UEFI.
Post 29 Nov 2016, 15:02
View user's profile Send private message Reply with quote
Display posts from previous:
Post new topic Reply to topic

Jump to:  


< Last Thread | Next Thread >

Forum Rules:
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001-2005 phpBB Group.

Main index   Download   Documentation   Examples   Message board
Copyright © 2004-2016, Tomasz Grysztar.