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.
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.
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:-
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
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 '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
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
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.
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
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