WHere to get enough info abt it. Is it very tough to do? What should one know to get into it?
Posted on 2001-06-04 04:32:00 by MovingFulcrum
the toughness depends on the functionality. If you use a non-proprtional font, like Courier, it is not very complicated. More difficult with free fonts, and much more complicated with support for localized windows versions, like Arabic Windows. Maximum difficulty with RTF format support, like wordpad.exe with bold, italic and different font sizes. From Windows you get a litle support with the Caret API. Common problems: marking text with mouse, scrolling, clipboard support, insert/overwrite modes.
Posted on 2001-06-04 10:06:00 by beaster
How are these functions made? Where can iget info abt it? Any soucre codes available?
Posted on 2001-06-04 10:26:00 by MovingFulcrum
codemax has their control. it's in c++ though, and trying to read the source is like trying to understand the last page of a novel without reading the rest of the book. i'm also working on one for irc clients. i have no idea when it'll be finished; i've been lazy. it will be open source when i'm done with it though.
Posted on 2001-06-04 13:12:00 by Sloat
Cant it be done in asm? U have told me codemax but u havent given me their webaddress. Also is it done in a dll or is it coded in the main exe prog itself. Arent their any C codes?
Posted on 2001-06-05 01:24:00 by MovingFulcrum
hi you can get CodeMax here: http://www.winmain.com/. i'm also very interested in coding this custom edit thing, but i haven't tried CodeMax yet(maybe i will).. how would one start making this? would it be like, making a procedure to deal with the input and process the necessary stuff, and then register this new class window start creating windows as needed and processing the USER+xxx messages in the WndProc? to begin i would just want to make a simple edit control, like the multiline edit one, if i could do that then i could proceed for the next stages: adding the ability to color words with different colors(the highlight thing), being able to open huge files without loading everything in mem(just loading what the user wants), having the possibility to insert weird math symbols and edit the little numbers:D next to them, different font sizes.. humm.. ok, i'm dreaming:D.. for now i would like just to start:).. any tips? ensein
Posted on 2001-06-05 11:32:00 by ensein
Well i wanted to see more replies in this one. Are we two the only ones working on one. Which means allu ppl making IDE's out there are relying and limiting urself to the libraries micro$oft has given u? Comeon guys that would mean implementing only those functions which they want us to have in our progs. Then how cum u ppl think of making big progs? how cum u think of beating thins like ultraedit and all when all u use is what is thrown towards u form micro$ft!!!!!!
Posted on 2001-06-05 13:04:00 by MovingFulcrum
MovingFulcrum, Are you serious? When you need some different functionality, you create it. Have you read any of Iczelion's tutorials ? Check these, Tut 20 (Window Subclassing) Tut 22 (Window Superclassing) Tut 32 (Multiple Document Interface) Tut 33 (RichEdit Control - Basics) Tut 34 (RichEdit Control - More Text Operations) Tut 35 (RichEdit Control - Syntax Highlighting) They should get you going in the right direction.
Posted on 2001-06-05 13:45:00 by anon
Anon, while this is true, they still make use of a common core component designed "robustly" by microsoft. The fact they are to be "robust" implies the control will often have extra code for cases used in each application. This causes overhead, and is why this thread has come to be... Try using your MOUSEWHEEL on a Iczelion's syntax highlighting tutorial. The overhead causes the control to respond slowly and a bit choppy. The common discussion of this alternate is Ultra Edit's pseudo RichEdit Control. It responds perfectly to the mouse and has many fuctions that have been written for the purpose of being a very practical edit window. MovingFulcrum, I can say I too am interested in this thread, but i dont think i have any technical advantage to add to the discussions :( . I would be happy to co-research this topic but i dont see a good starting point as of yet. NaN
Posted on 2001-06-05 18:05:00 by NaN
The first book I read on assembly programming was centered around writing an editor in 68000 assembly. ( I still owe the library for that book - I never returned it - I got some jam on it. :) ) There should be many C sources on the web for editors - it's one of the main topics that new programmers tried to tackle a few years ago. 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." ;) It is by no means a trivial thing, but I see no reason it couldn't be done in asm, again (for windows this time). You could look on SimTel.net for some old sources to get a basic understanding of some of the methods used in editors. I'm not really sure what advancemants have been made in the last ten years. The was an editor I used in DOS a long time ago that did code-completion (text prediction type thing). So, I don't think anything has really happened with the basic editor concept.
Posted on 2001-06-06 11:57:00 by bitRAKE
MovingFulcrum, The task you have in mind is an enormously complicated one where there is probably NO technical data available at all. Editors, word processors and similar text editing capacity is usually proprietry and secret information that is developed by a team of programmers over a long period of time. You need to design from scratch the screen control for a caret, design a memory scheme to control parts of the test, formatting control for fonts, scrolling mechanisms, search mechanisms and the list goes on and on. Edit controls and rich edit controls save you most of the hassle and are built into the operating system so unless you want to do something that they cannot do badly enough, I would be inclined to adapt one to your needs. Regards, hutch@pbq.com.au
Posted on 2001-06-06 19:44:00 by hutch--
Please look at Windows Programming by Charles Petzold on Chapter 6 and the sample typer.c. It is a basic editor(?!) to type in one full screen of text. Probably you will get a glimpse of what you are at. Jones.
Posted on 2001-06-07 00:16:00 by sjhenry
I have an idea. Cant the original RichEdit dll be hacked into by a disassembler or a debugger and the code be studied. I know that it wont be too legal to do that but i dont want to do any harm or reverse engineer the existing richedit dll or anything, i just want to study the code of it. Can any1 tell me which proggie would be the best for this? Also i would like ur suggestions on this. I dont have the Windows Programming book with me and the country where i live its almost impossible to get it. I would be grateful if u can send me the C source code of that prog. Also can it be that the existing editcontrol is give n so much functionality that it can do almost anything i want? Hvae these UltraEdit guys out there done the same or have they made a custom editcontrol of their own? This message was edited by MovingFulcrum, on 6/7/2001 12:25:56 AM This message was edited by MovingFulcrum, on 6/7/2001 12:31:31 AM
Posted on 2001-06-07 00:22:00 by MovingFulcrum
I have a book called "Windows Custom Controls". It's a 16-bit Win 3.1 book. But it has 8 custom controls, ranging from check boxes with changable checks, to radio buttons, to virtual-memory custom list, to static and frame and other controls. It states that Windows Controls use GDI to draw and scale their borders and text and colors and what have you, but the exapmles used non-scalable bit maps for simplicity. It's not on the shelves anymore. I think it had a custom spreadsheet control, too. Also teaches very well how to package your controls into a dll to be used by a resource editor and such. I saw a book once (and didn't get it, now I'm hard pressed to relocate it since I don't know the title, only what it looks like)... that actually discussed the same thing. Only, it started a custom color edit control from scratch. Not based on any existing control. It had logic for managing various fonts, colors and stuff. Not quite as functional as a richedit control. But, 400 of the 800 pages were dedicated to the basics of the controls and much was source code in 8 pt. text. The other 400 pages detailed advanced topics like memory management, and extending it's 64k limits to 4GB. Things we take for granted like inerting text where we will, were no laughing matter in a custom implementation. Anyway, my point, you can start from scratch if you will. However, it's easier to extend an existing, such as richedit. I strongly believe that's what UltraEdit does. It's a custom control, but it's based on RichEdit. Some Delphi controls that are equally as functional as RichEdit, are custom from scratch. But it's much easier to do in Delphi since all the base classes already exist and font management and memory management. Have fun, _Shawn
Posted on 2001-06-07 12:10:00 by _Shawn
Ok ppl. I have found the answer to our problems. I dotn know whether many of u know this or not but Star office has gone open source. Its source can be downloaded from www.openoffice.org . What could be a better example for a custom edit control than the source of one of the best word processors around. The file is quite big , arnd 50 mb. I havent yet dl it. But from the details give on the page it seems the thing is coded in C++ :( . But still something is better than nothing :)
Posted on 2001-06-08 22:07:00 by MovingFulcrum
Reversing RichEdit is a bad idea. Not because it's illegal, but because it's going to be one hell of a dead listing. Just look at the size of the DLL file. YUCK - and a fine reason for implementing your own custom control. As for looking through staroffice... it's a rather huge amount of source code, and there's probably a lot of various dependencies all around. And if it uses MFC... good luck :). I'd say the best path is to start from scratch. And start with something (reasonably) simple. Like, being able to use only a single font, and perhaps even only a monospace one. There should be color support, and coloring of different words, for use with syntax highlighting. No mouse-selection support. Something like that *should* be possible to code without growing too much grey hair :).
Posted on 2001-06-11 15:02:00 by f0dder
I like ur advice f0dder, but the thing is absolutely no code exist on the web which can at least serve as examples or starting point for me to begin with. The link to the codemax site u see in posts abve has a source which is full of MFC usage. What i need is somestarting point for me start coding one. Can anyone here pls direct me to any??
Posted on 2001-06-12 14:46:00 by MovingFulcrum
If you can read C++/MFC try :- codeguru umbongo
Posted on 2001-06-12 14:57:00 by umbongo
Okay, I wasn't going to do this at first, but I thought I'd give it a try. I did some homework on various resources for creating custom API controls without MFC or VCL... A complete button class from scratch in C Custom Windows Controls (Win 3.1 -- but useful, I have it) Windows Custom Controls (Amazon -- might be used for sale, maybe not) Windows Programming Power w/ Custom Controls (Amazon -- maybe used for sale, maybe not) Custom Edit Control Tutorial (C++ -- NO MFC/VCL/OWL/ETC) Hmm... this is all I can find. Looking through hundreds of google and altavista listing on custom edit controls, amazingly, everything that is useful has broken links or is MFC/VCL based. The best I can say in this case, is to learn how to convert MFC/VCL classes into raw API. There was nothing that described how to start one from scratch tho I've seen a book on it once. Everything extends the existing Windows Edit control or RichEdit control. I've seen some excellent Delphi components in that area, and it extended the windows edit control. Nonetheless, for Assembly purposes and raw C, there is little available :( Good luck, _Shawn
Posted on 2001-06-13 02:56:00 by _Shawn
MovingFulcrum, I tried to warn you that this type of info is proprietry in most instances so it will not be available. Try playing with the text display functions in Windows, TextOut(), DrawText has some formatting options that may be useful. You have to design a memory scheme for the text depending on what you want to implement and you have to ba able to upgrade the screen on each keystroke. Then you need caret control to know where the text insertion point is. The API functions are there to do it but there is one hell of a lot to learn to do what you need. Good luck with it. hutch@pbq.com.au
Posted on 2001-06-13 04:40:00 by hutch--