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.
Posted on 2001-06-13 05:43:00 by Betov
Well, betov. If you start with a simple control, you learn how to do the stuff. You'll probably end up having to rewrite from scratch to add proportional fonts et cetera... but who says that's a bad idea? A first-try control will probably have a lot of flaws anyway, so a total rewrite is probably a good thing, learning from your experience with the simple control. As for using a flat-memory approach... why would you want to do that? For editing huge (and I mean HUGE) files, it will be very crappy. Even a 700mhz athlon with 512megs of ram is not going to like deleting or inserting bytes in the middle of a 200meg file. Yeah, I occasioanlly deal with text files that large. What's wrong with a line-based approach anyhow? As far as I can see, it makes the "rendering" of the text easier, as you know where lines end and start, and don't have to parse for CRLF (or LF or whatever) all the time. Sure, your heap might get a bit more fragmented with a linebased editor, but tricks can be used to make this as little as possible (dynamic line-string reallocation with some delta to avoid a realloc on each added char), and you can put each file in it's own heap so that there isn't so much fragmentation when you close a file. And a flat approach might end up becoming even more fragmented than a line-based approach, if not done correctly. But if you can tell me of any advantages of using a flat approach, please enlighten me.
Posted on 2001-06-13 06:59:00 by f0dder
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
Posted on 2001-06-13 11:52:00 by umbongo
Well its not impossible to do so it can be done. Right now i am learning some c++ to know something abt classes and stuff. Then i will go on to understand some MFC and finally come back to see and understand the code of the codemax editor. The speed of the codemax editor i have noticed is much faster than the richedit dll (atleast in opening files it is, thats the only thing i have tested till now). I see that is the only good and professinal source code available. StarOffice is also good but i have heard that it is quit slow. Also a 60mb dl on my 56k modem would take months ;) This message was edited by MovingFulcrum, on 6/17/2001 9:21:10 AM
Posted on 2001-06-17 09:10:00 by MovingFulcrum
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
Posted on 2001-06-17 22:52:00 by Larry Hammick
Larry, Thats why i am so interested in ultraedit. They seem to have modified the richedit control to its best without making a custom control of their own.
Posted on 2001-06-18 06:45:00 by MovingFulcrum
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
Posted on 2001-06-18 16:55:00 by _Shawn
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. www.richview.com also has one, called RichView, which is a rather unique, highly featured, plug-in enabled, customer-from-scratch editing control as well. Might give it a shot. Source is included with $60 purchase. I have a few books and have seen a few resources, but I've searched the Internet up and down looking for answers for your question and have not found anything useful. However, I started looking at MFC controls and VCL (I never programmed MFC before) and found, that all the answers you need are there, just get an undeserstand of the cWnd class which is the base of all windows in MFC, and you're off to a really good start. _Shawn
Posted on 2001-06-18 16:58:00 by _Shawn