How to capture the OnPaint of a textbox

[Tom P.]

I'm trying to make one of our perennial favorites - The Syntax Color
Editor. (Mostly as a learning exercise). I'm wondering if there is a
way to capture the Paint event of a textbox so I can render the text
myself.

I've tried to replicate the functionality of a textbox, but I think it
would be easier to simply take over the painting of a plain textbox.
Then I wouldn't have to deal with several problem areas I'm currently
running into.

Thanks for any help.

Tom P.

[raylopez99]

On Aug 25, 7:37*am, "Tom P." <[e-mail]:

I'm trying to make one of our perennial *favorites - The Syntax Color
Editor. (Mostly as a learning exercise). I'm wondering if there is a
way to capture the Paint event of a textbox so I can render the text
myself.

Unless the Textbox class has a .Draw method associated with it, as
ImageList does for example, I would imagine it's hard to do this, but
I'm just guessing.

RL

[Ignacio Machin ( .NET/ C# MVP )]

On Aug 25, 10:37*am, "Tom P." <[e-mail]:

I'm trying to make one of our perennial *favorites - The Syntax Color
Editor. (Mostly as a learning exercise). I'm wondering if there is a
way to capture the Paint event of a textbox so I can render the text
myself.

I think that the textbox not the best base class for this. A
RichTextbox would be more suited for the task.

But in anycase, you can derive your class from Textbox and handle the
onPaint event. There are eamples of how to do it. Do a search of
"owned draw controls"

[Tom P.]

On Aug 25, 10:26*am, "Ignacio Machin ( .NET/ C# MVP )"
<[e-mail]:

On Aug 25, 10:37*am, "Tom P." <[e-mail]:

I'm trying to make one of our perennial *favorites - The Syntax Color
Editor. (Mostly as a learning exercise). I'm wondering if there is a
way to capture the Paint event of a textbox so I can render the text
myself.

I think that the textbox not the best base class for this. A
RichTextbox would be more suited for the task.

But in anycase, you can derive your class from *Textbox and handle the
onPaint event. There are eamples of how to do it. Do a search of
"owned draw controls"

Have you ever tried it? I did last night and the OnPaint method never
gets called (RTEdit as well). There is no OwnerDraw attribute for
TextBox and the best I can do is call InvokePaint and
InvokePaintBackground when the text changes. This may be what I'm left
with unless I can get this question answered. Or trap the WndPrc
message and parse it.

Thanks,
Tom P.

[Peter Duniho]

On Mon, 25 Aug 2008 08:26:02 -0700, Ignacio Machin ( .NET/ C# MVP )
<ig************@gmail.comwrote:

On Aug 25, 10:37Â*am, "Tom P." <[e-mail]:

>I'm trying to make one of our perennial Â*favorites - The Syntax Color
Editor. (Mostly as a learning exercise). I'm wondering if there is a
way to capture the Paint event of a textbox so I can render the text
myself.

I think that the textbox not the best base class for this. A
RichTextbox would be more suited for the task.

But in anycase, you can derive your class from Textbox and handle the
onPaint event. There are eamples of how to do it. Do a search of
"owned draw controls"

Though, it begs the question: why derive from TextBox _or_ RichTextBox in
this case, if not to let the base class do the drawing? The drawing will
be closely dependent on other control state internals, such as current
selection, scroll position, and of course the actual formatted text.
Trying to do all the drawing oneself while coordinating with these other
things would be extremely complicated and prone to error. And besides, if
doing the drawing oneself, what's the point of inheriting RichTextBox?
The main difference between that and TextBox is the visual appearance of
the text, so if doing all the drawing oneself, why bother?

I think I would do one of three things:

-- inherit RichTextBox, but rather than overriding the drawing
behavior, add new text management members that automatically format the
incoming text. Unfortunately, the original text management members can't
be overridden, and this approach would be somewhat brittle (easily
bypassed by other code and user input).

-- compose RichTextBox into a custom control, delegating text
management and rendering to the RichTextBox control. This would address
the exposure to code in the first solution, but not necessarily the user
input issues (though maybe there's a way to intercept user input to
control/block things that might mess with the composed control).

-- write your own control. This is more complicated, obviously, but
it's not an impossible effort (in fact, I'd say that once you get the
basic concepts of custom controls down, it's not all that hard...just
time-consuming). The advantage is of course that with a completely custom
control, you have complete control over the behavior of the control.

Pete

[Tom P.]

On Aug 25, 11:11*am, "Peter Duniho" <[e-mail]>
wrote:

On Mon, 25 Aug 2008 08:26:02 -0700, Ignacio Machin ( .NET/ C# MVP ) *

<[e-mail]:

On Aug 25, 10:37*am, "Tom P." <[e-mail]:

I'm trying to make one of our perennial *favorites - The Syntax Color
Editor. (Mostly as a learning exercise). I'm wondering if there is a
way to capture the Paint event of a textbox so I can render the text
myself.

I think that the textbox not the best base class for this. A
RichTextbox would be more suited for the task.

But in anycase, you can derive your class from *Textbox and handle the
onPaint event. There are eamples of how to do it. Do a search of
"owned draw controls"

Though, it begs the question: why derive from TextBox _or_ RichTextBox in*
this case, if not to let the base class do the drawing? *The drawing will *
be closely dependent on other control state internals, such as current *
selection, scroll position, and of course the actual formatted text. *
Trying to do all the drawing oneself while coordinating with these other *
things would be extremely complicated and prone to error. *And besides,if *
doing the drawing oneself, what's the point of inheriting RichTextBox? *
The main difference between that and TextBox is the visual appearance of *
the text, so if doing all the drawing oneself, why bother?

I think I would do one of three things:

* * *-- inherit RichTextBox, but rather than overriding the drawing*
behavior, add new text management members that automatically format the *
incoming text. *Unfortunately, the original text management members can't *
be overridden, and this approach would be somewhat brittle (easily *
bypassed by other code and user input).

* * *-- compose RichTextBox into a custom control, delegating text *
management and rendering to the RichTextBox control. *This would address *
the exposure to code in the first solution, but not necessarily the user *
input issues (though maybe there's a way to intercept user input to *
control/block things that might mess with the composed control).

* * *-- write your own control. *This is more complicated, obviously, but *
it's not an impossible effort (in fact, I'd say that once you get the *
basic concepts of custom controls down, it's not all that hard...just *
time-consuming). *The advantage is of course that with a completely custom *
control, you have complete control over the behavior of the control.

Pete

I had already started down the path to writing a custom control,
inheriting simply from the Control object, when a friend of mine
suggested the TextBox thing (i am having issues placing the carat but
it's just a matter of math and string length, separating text into
lines etc.).

I think you are correct that, oddly enough, the simplest thing to do
is skip the textbox altogether and write my own. This will also give
me space to do things I want like gradient backgrounds (I heard they
are easier on the eyes than flat white).

Tom P.

[Peter Duniho]

On Mon, 25 Aug 2008 08:56:34 -0700, Tom P. <pa***********@gmail.comwrote:

[...]

>But in anycase, you can derive your class from Â*Textbox and handle the
onPaint event. There are eamples of how to do it. Do a search of
"owned draw controls"

Have you ever tried it? I did last night and the OnPaint method never
gets called (RTEdit as well).

For many of the built-in Forms controls, even if OnPaint() is called (and
as you've seen, often it's not), that's not where the drawing actually
happens, because the control is just a wrapper for an unmanaged control.
You'd have to override WndProc and intercept WM_PAINT messages to actually
override the drawing.

Pete