|
No, ColorTextBox is not intended to be a WYSIWYG editor. Calculating and rendering lines with different fonts is very costly and would slow down the whole component significantly.
However you can extend ColorTextBox to support different fonts, which requires some work as you have to override (nearly) all methods responsible for line drawing and calculation of the line metrics.
Unfortunately I do not have the time to do this, but if someone is willing to do so I'll be glad to assist!
|
|
|
|
|
:-DHi,
first of all, I have been looking for this control for sometime. I test the control using VB.NET. I want to be able to change textcolor on the fly, eg highlight words or whole line, etc
Issue, when set color, eg. ctb.SelectColor = Color.red, and type character. The color will not change. The color change only when you mark chars and change it using same property.
It seems that control allow only text color when you have text selected,then any char typed color will change.
Quesion: Can we change color of text at the cursor ?
|
|
|
|
|
Hello!
You're right! This is definitely a nasty bug - I will fix this in the next release!
Regards,
Christian
|
|
|
|
|
Hmm, on a second thought I'm not quite sure what you're trying to achieve... I know there is a bug when you type text and press Enter while the caret is not positioned at the end of the document. In that case the documents' color will change to the color of the text after the caret. Furthermore copy and paste of colored text coming from the ColorTextBox is currently not supported (although I know that this feature has worked before 
However I'm unable to reproduce the behaviour you described - if you set the color with the SelectionColor property all characters will be inserted with that color.
However if the caret position changes after a call to SelectionColor the color will be set to the color at the new caret position.
Greetings,
Christian
-- modified at 14:18 Wednesday 21st March, 2007
|
|
|
|
|
Hi Christian,
Thank you for response,
What I want to archive is to use the control to function as Terminal emulator where I can change color of text before insert chars. For example, if a line of text received contain certain words, I may change color at the begining of the line and insert text, and reset color to normal. Or even highlight words with background color.
I also noticed your bug as you described. To get round that we just need to make sure that caret is at the end of the line.
Is there that we can fix it so that evry char inserted will be specific color, no matter where caret is ?
Is there a problem with focus while setting color properity ?
sanong
|
|
|
|
|
Hi!
I uploaded a new version which hopefully solves the issues you were having!
Regards,
Christian
|
|
|
|
|
Hi Chris,
Thank you.
I will definitly test it.
sanong
|
|
|
|
|
First of all, even though you think your design is not so good, it is the fastest.
Mind you, even leaving along the coloring, we don’t have even satisfactory edit control, for .NET or native Windows. Window’s EDIT lacks important events (like cursor position changed) and also has poor performance; Rich Edit has several severe glitches; some of them are only manifested on big files (I’ve developed my own rich-edit based editor and had a hard time to find some work-arounds).
As to the #developer’s edit control, for some applications it is unacceptable, because it renders way too slowly when the file size is about 2M or more.
So, I would encourage you to work your control in a comprehensive lightweight component. First of all, would you please some of your bugs? Here are some I found (and fixed one of them):
1) You’re missing KeyDown events Ctrl+Ins (copy), Shift+Del (cut), Shift+Ins (paste), “old” CIU-style equivalents (actually, more convenient) of Ctrl+C, Ctrl+X, Ctrl+V.
2) PgUp(PgDown) works incorrectly: it just scrolls, but it MUST also change caret position.
3) RenderMode.GDINative does not work with Unicode; shame on you: working with .NET and P/Invoke you should not forget using “Wide” version of Windows API names and proper marshalling for the.NET type “string”. Please see my fix below but look carefully: generally, you’re supposed to add “W” to all API names.
4) Another RenderMode.GDINative problem: text background color differs from that of control – it’s some close “rounded-up” color.
My fix of bug (3): file Win32Wrapper.cs:
<br />
[DllImport("gdi32.dll", EntryPoint = "ExtTextOutW")]<br />
internal static extern bool ExtTextOut(IntPtr hdc, int X, int Y, uint fuOptions,<br />
[In] ref RECT lprc,<br />
[MarshalAs(UnmanagedType.LPWStr)]<br />
string lpString,<br />
uint cbCount, int [] lpDx);<br />
<br />
[DllImport("gdi32.dll", EntryPoint="TextOutW")]<br />
internal static extern bool TextOut(IntPtr hdc, int nXStart, int nYStart,<br />
[MarshalAs(UnmanagedType.LPWStr)]<br />
string lpString,<br />
int cbString);<br />
<br />
[DllImport("gdi32.dll", EntryPoint="GetTextExtentPointW")]<br />
internal static extern bool GetTextExtentPoint(IntPtr hdc,<br />
[MarshalAs(UnmanagedType.LPWStr)]<br />
string lpString,<br />
int cbString, ref Size lpSize);<br />
Design consideration: caret info area as a part of control is not appropriate. Instead, you should provide just a public event. The user most likely will process this event by updating status bar or something like that.
Lack of feature: how about Word Wrap (#developer’s editor does not have it either)?
Thank you.
--SA
Sergey A Kryukov
SAKryukov
|
|
|
|
|
First of all, thanks for the very constructive input! Concerning the bugs you mentioned:
1. KeyEvents:
Since I do not acutally use the control very much I didn't pay much attention to standard key event handling, but I'll try to implement the missing features as soon as possible!
2. PageUp / PageDown:
Same here: will be implemented in the next release!
3. GDINative rendering:
I implemented this rendering path to do some performance comparsions and I think it doesn't really offer great benefits in that area (maybe it does on slower machines, but I do not have the possibility to verify this as I do not own a sub-GHz PC anymore). Besides the bugs you pointed out (I wasn't aware of the Unicode issue - thanks) there are still other problems involved with native GDI rendering. A long story short: it simply doesn't work the way it's supposed to and should currently not be used. I'll add a comment to the enum value to point that out until I have the time to fix it (of course I'll add the fix you provided to the next release, but as I said there are still some other issues to solve!)
4. Background color for GDINative rendering:
See point 3.
Concerning the caret info area inside the control - let me put it the Microsoft way: "This behavior is by design."
In fact one major feature of the control is the support for reserved areas at the edges of the text area which allow easy extensibility in subclasses. Let me copy / paste the description of that feature from the source code:
So if you do not want to show the caret info area you can simply disable it with the respective property. Additionally I will add a public CaretChanged event to support external handling of caret events (the way you suggested).
I hope this helps!
Regards,
Christian
|
|
|
|
|
Good enough.
So, what are your plans for next release?
Thank you.
--SA
SAKryukov
|
|
|
|
|
There will be mainly bugfixes, no new features. I'm currently working on the support for various key events (TextPad acts as a reference here). As you requested, there will be a public CaretChanged event and I will try to fix the scrollbars which currently cannot be disabled. That's it for now - expect a release next week.
Greetings,
Christian
|
|
|
|
|
I cannot input Polish letters like an "ą" (Right Alt + a). It looks like Alt+letter is interpreted like Ctrl+letter.
|
|
|
|
|
|
Any plan to support wordwrap?
--
Quentin Pouplard
http://myoedev.blogspot.com
|
|
|
|
|
I thought about that feature for a long time, but as I already mentioned below the general design of the control is not very well thought out. It would require some work to implement such a feature and since I'm not a student anymore I fear I won't have time for that... at least not any time soon. Sorry.
|
|
|
|
|
Hello,
Thanks a lot for this control, it's working great.
Any luck for the wrapping feature? that would be so handy 
Thanks again for your work,
Philippe
Philippe
|
|
|
|
|
Hi,
First, I wanted to congratulate you for the real nice work you did. After having searched for quite a long time for this kind of control in c#, I must admit this is the first open source (free) one that seems really worst to use.
I checked your demo application, and really I haven't tryied it much yet but after 2 min of testing, I figured out that it doesn't behaves well with "Select All" (when you press CTRL + A) which is a shortcut I mostly use when working with text editors.
Furthermore, keyboard keys combinaison like:
SHIFT + END (to select the whole line)
SHIFT + HOME (idem ...)
CTRL + LEFT/RIGHT ARROWS (to jump with the caret from word to word)
There are certainly a few more combinaison I didn't mention here, but if the meaning of this control is to be usable in some kind of "coding" or even "text writing" context, I think those shortcuts are mandatories in order to give the best user experience.
Anyway, your control is wonderfull (I like the caret information bar).
Best Regards,
Mike.
|
|
|
|
|
Thanks for the positive feedback. The features you requested should be very easy to implement, so I will try to add them as soon as possible!
|
|
|
|
|
Any update on this? Really would like CTRL + Z
|
|
|
|
|
Hi!
i'm currently working on a code editor, and i was using another hihglighting tool.. it has some bug that i haven't been able to solve, so this solution you giving mught become a better option...
i just downloaded the source from sourceforge but i haven't been able to figura waht does:
ColorTextBox_Key.pfx means.. it asks me for a key or password or something.. what should i put there?
Thanks!
By the way, i'm from colombia, sei um poquinho de português :p
|
|
|
|
|
The *.pfx files are used for signing the assemblies, so they are not needed for building the project and can be deleted.
Concerning syntax highlighting: the approach I used for LMX-Editor is rather unconventional (because of the complex grammer of the LMX notation) and does not use syntax definition files. So if you want syntax highlighting in an own implementation of the abstract CodeTextBox class there are basically two options:
1. You can implement your own highlighting class which uses syntax definition files and whose interface is compatible with the abstract SyntaxHighlighter base class.
2. You can provide a concrete implementation of the abstract SyntaxHighlighter class which uses a Coco/R generated scanner for highlighting. If you have the grammar of the language you want to highlight in EBNF this is the preferred way as it's much less work (most of the methods in SyntaxHighlighter are already implemented)
The first option clearly requires much more work but since LMX-Editor doesn't use this approach I have not implemented such a highlighting mechansim yet.
|
|
|
|
|
written from scratch is right!
at first glance, this doesn't look like it's quite on par with solutions like compona's free textbox or #develop's free textbox, but it sure is an awesome start!
|
|
|
|
|
You're right. The basic design of the control (especially concerning the data structures) is not very good, which is partly due to the evolutionary development approach. I simply wasn't aware of many requirements when I started development...
|
|
|
|
|
|
bang bang 
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
