Ah, then I would have expected the question to ask about the scrollbars,
"buttons", which are a separate control.
And, I believe that the answer is "You cannot do anything about this" (the
answer is "you will have to handle the OnNcPaint event and paint the
non-client area for
yourself) but that is not something most expienced WIndows programmers
would choose to
undertake, let alone a novice.
Thanks for your answer. I just wasn't sure if going the OnNcPaint route for
a CEdit would be something feasible knowing that CEdit kind of "fights"
against custom drawing.
There is another answer: create a separate scrollbar control and use it.
This is the
solution usually proposed in kiosk situations where a large touchable area
I think this would be a good compromise.
But the question was ill-formed, and was asking a detail of how to
instead of asking how to solve a problem, e.g., "I have a touch-screen
situation and I
need to make large touchable scrollbars, what is the best recommendation
for how to do
this for an edit control?"
Sorry for not stating clearly what the purpose of my question really was.
Here is an explanation: I am developing an application that uses my own
custom controls (buttons, comboboxes, listboxes,
and so on.) I do my own text drawing ( I have my own DrawText function
because I use actual png's for each letter because I wanted to design a font
that would contain shadows so that I could alpha-blend the letter nicely on
the background, etc. I know, not terribly flexible, but good enough for my
needs and it looks really really good). My DrawText function takes a
rectangle and renders a text in it. It supports text alignment
(vertical,center,etc), multi-line, etc. The only problem is that it doesn't
support "text scrolling" in either direction (horizonta/vertical).
Therefore, I found myself in the situation of having to develop my own
CEdit-like control. I got pretty far: my edit control behaves as a CEdit
except that I didn't implement block selection and it does not have a scroll
bar yet. Furthermore, I still have to fix a few bugs relating to caret
positioning. Unfortunately, I never expected to write a CEdit-like control
that would have to support more than a "page" of text (page being defined by
the height of the control). Therefore, I designed my initial code with this
limitation in mind. Now, when I continued the development to support other
pages of text as well, I realized that my design wasn't quite right (instead
of having concepts such as rows, columns, etc) I just had images rendered on
the screen (representing letters). Therefore, all the cursor positioning
(via keyboard or mouse) was done at pixel level. I would check where the
user clicked in terms of x and y coordinates, I would find what row of text
is associated with the particular y coordinate, I would iterate through the
text adding the widths of each letter to determine after what letter the
caret should be positioned and so on. Basically, a wrong design that got to
be a headache after adding scrolling and so on. Now, I realized that it
would be much easier to just use the CEdit because I don't want to spend too
much time on this (sure, I will continue to develop my own CEdit-like
control, but that will take quite a while) so for now, I wanted a
compromise: I wanted to somehow customize the drawing of the scrollbar and
buttons but didn't read much about this because I remembered that CEdit is
not really designed to allow you to do too much customization of its
Thanks for your suggestion.
__________ Information from ESET NOD32 Antivirus, version of virus signature database 5036 (20100417) __________
The message was checked by ESET NOD32 Antivirus.