ASM Community

MovingFulcrum, the idea of Fodder (Starting with a simplified version for fixed fonts) is, at my opinion, a bad idea. I have written my own Source Editor for SpAsm this way, because, for Asm programing, we need fixed fonts only. But i can swear you that, if i would be willing to turn it proportional now, i would have to rewrite it entirely :( Another thing: All the examples and tuts you will see are based on good old time practice. When computers were slow, we had to think of the Editors as a collection of Lines Editors. Actually, with the incredible power and speed of processor and great increase of flat mem size, we can think of it as a full huge files Editor aplying all actions upon the whole Data. Example, when you enter one char in SpAsm editor, let's say at the begining of a 1 Mo source, all the data that follow this char are moved one step down (very rude and simple). This is something that would have been totaly impossible in good old time. So, don't consider examples as anything else than good infos to be considered (not as a work base). If your plan is to write something to compete with UltraEdit, be prepared to YEARS of work. A little unsignificant and durty chiet like the Sources Editor i wrote for SpAsm (-i mean 'unsignificant as a Text Editor'- that was a requirement because i was in need of Asm functionality that i couldn't have another way), took me about 8 months, and i still found one little bugs in it last week, one more year later, whereas i use it everydays, at least 8 hours a day... Customising RichEdit is an unpleasant but reasonable solution. As Ewayne already works on this project for Asm edition and is much advanced and serious work, this could be a short way. The results in true Assembly would, of course, be a bit better than the ones of RichEdit, but, not so much. RichEdit is one of the things inside windows, with BitMaps management, that are the more estonishing (i mean, good quality, speed and flexibility -if written in C-). betov.

Using a line based approach you can make the file as long as you like, all you need is a double linked list so you have a structure like this:-

LINE STRUCT DWORD
  pPrev   DWORD      ?
  pNext   DWORD      ?
  pData   DWORD      ?
LINE ENDS

Then if you delete a line, you can remove the entry from the link, and if you insert one you can add one in. Iterating through the list is easy, and the pData item is just a string to print, so it's not very difficult. Line numbers are found by iterating through the list. I was working on a syntax hi-lighted editor many years ago, and this was the best way of doing it we found. There are others, but they are all based on this kind of scheme. If people edit very short lines, then the overhead per line is big, it's a minimum of 14 bytes for 1 character in a line. After that it's linear, 2 chars in a line will only take 15 bytes. If it was for an assembler then ' pop eax' is only 8 chars, but needs 21 bytes to store it. almost 3 times as much as the text itself. alloc and realloc aren't such a problem these days, Windows can shift things around for you to make room, which in old version it was never able to do. That said, I would allocate blocks of 100 linked-list entries at a time, to keep it to a minimum Also maintain two lists, one used list and one free list. When a line is delete it is moved to the free list, and it's pData deleted. When you insert a line, take an entry from the free list and use that... I'm just waffling now... I'll shut up... umbongo

Nice quote from bitRAKE: Somewhere along the way all dos/unix programmers say either, "I'll rewrite the compiler" or "I'll rewrite the editor" or "I'll rewrite the OS." The editor LaTex for mathematical stuff is unbelievably complicated. Legalities aside, disassembling Microsoft stuff, with the intention of improving it, is poor strategy. You can improve it alright, but you will get there much faster if you start from scratch, whatever the app might be. Don't ask how I know, but I know :D

I forgot to mention, I know you're not into Delphi probly. www.dreamcompany.com has a control called Dream Memo. It's VCL based, but if you look at the sources, they created a control a little more powerful than the UltraEdit text control from scratch. I'm looking at the sources and planning on learning how to write custom edit and windows controls from scratch in C without MFC or VCL... however, I need those frameworks to dissect. _Shawn