ColorTextBox

:-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 Wink | ;-)

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 ?

Confused | :confused:

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:

/* Reserved areas are regions that can be added to the four sides of the client area for user
 * defined painting. The line rendering will always be limited to the area surrounded by all
 * reserved areas that have been added to the Control. To add a reserved area the width or height
 * of the area, the location of the area and a method responsible for drawing the area have to be
 * supplied. Reserved areas need to have a unique identifier string for a given location and can be
 * inserted at a given index (starting with 0 for the innermost area)
 * For clarity the follwing graphic shows the concept for a ColorTextBox with 1 top, 2 left,
 * 1 right and 2 bottom areas:
 *
 *       _________________________
 *      |____________0____________|
 *      | | |                   | |
 *      | | |                   | |
 *      |1|0|     Text Area     |0|
 *      | | |                   | |
 *      |_|_|___________________|_|
 *      |____________0____________|
 *      |____________1____________|
 *
 *
 * NOTE: It's not recommended to put a lot of complex logic inside the registered draw method of a
 * reserved area as this can slow down the whole rendering process significantly!
 */

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.

Fixed! Regards, Chris

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 Smile | :)

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

booga booga

bang bang

[VisualCalc][Binary Guide updated! ][CommDialogs new! ] | [Forums Guidelines]

ColorTextBox

Introduction

Background

Using the code

Points of interest

History

License

Comments and Discussions